Toon posts:

[php/mysql] Koppeling tussen betaalmethode en zijn opties

Pagina: 1
Acties:

  • ReenL
  • Registratie: augustus 2010
  • Laatst online: 22-03-2015
Ik ben (op werk) bezig met het programmeren van een webshop.

Op basis van de gekozen betaalmethode moet een bepaald formulier weergegeven worden. (Denk bij iDeal aan de dropdown met "Kies uw bank" en bij creditcard aan "creditcard nummer", "CVC" etc etc)

Zelf dacht ik aan de volgende MySQL tabel:
payment_method
- id
- name
- status

payment_method_form
- id
- name

linktabel
- payment_method_id
- payment_method_form_id

Zo kan je voor elke method een of meerder forms aanzetten (deze worden in de applicatie gemapped naar een zend form).

Nu was dit het voorstel van mijn collega:
payment_method
- id
- name
- options
- status

Waarbij options een text veld is en een yaml string bevat met daarin alle opties. Met het argument dat dit flexibeler is omdat je naast forms ook andere dingen aan de betaalmethode kan koppelen zonder je tabelstructuur aan te passen.

Mijn vraag is, wat zouden jullie de beste oplossing vinden en hoe zou je dat ten opzichte van het technisch opperhoofd beargumenteren.

De argumenten die ik tot nu toe bedacht heb:
- Door meerdere tabellen te hebben hou je overzicht wat er aan een betaalmethode gekoppeld is;
- Je kan met simpel een bepaalde optie uit/aanzetten globaal met sql;
- Een veld gebruiken voor meerdere typen data wordt in mijn ervaring meestal een rotzooi.

  • HuHu
  • Registratie: maart 2005
  • Niet online
Geen antwoord op je vraag, maar wel van belang: ga je zelf überhaupt wel de betalingen afhandelen? Als je iDeal implementeert, dan krijg je gewoon een vaste structuur van je bank en daar heb je je aan te houden. Betalingen met creditcard ga je waarschijnlijk ook niet zelf regelen, daar heb je een payment service provider voor. Kijk eens naar bedrijven als Ogone of RBS Worldpay, wat die voor je kunnen doen.

Voorbeeldje met iDeal: de lijst met banken waar jij het over hebt is onderverdeelt in een short-list en een long-list, met daartussen een scheiding met als label "overige banken". De lijst moet je eens per 24 uur ophalen bij je bank, vaker is niet toegestaan. De sortering van de lijst wordt ook bepaalt door je bank. Enzovoorts...

Het zelf bedenken van een structuur gaat zeer waarschijnlijk niet lukken. Je moet andersom werken, eerst kijken hoe je de betalingen gaat afhandelen en dan pas nadenken over de implementatie.

Ter leering ende vermaeck: http://www.rabobank.nl/im..._professional_2966322.pdf

[Voor 5% gewijzigd door HuHu op 14-10-2010 11:14]


  • ReenL
  • Registratie: augustus 2010
  • Laatst online: 22-03-2015
De betaalmethodes worden zo veel mogelijk zelf geïmplementeerd (ja we zijn pci certified en ja we hebben de "full" implementatie van iDeal en ja we gebruiken ook ogone). Dit is echter pas een paar stappen verder en daar maak ik me eigenlijk minder zorgen om.

Het gaat hier om een nieuwe versie van een reeds bestaande applicatie, dus de betaalmethoden zijn al eens door ons geïmplementeerd, we zijn echter niet tevreden met de flexibiliteit van de huidige applicatie.

De applicatie moet eerst weten welke data hij nodig heeft om een bepaalde betaalmethode in te schieten. Dit is dus per betaalmethode verschillend. De vraag blijft dus hoe jullie dit zouden oplossen.

  • Kalentum
  • Registratie: juni 2004
  • Laatst online: 13:54
Ik vind die aanpak van die collega wel ok. Zou ik zelf ook zo doen. Een soort van EAV, maar met met een erg beperkte toepassing.

Ik zou dan ook nog iets met een datum erin verwerken, zodat je aangekondigde wijzigingen (veldje er bij, eraf) alvast klaar kunt zetten en bovendien weet hoe de formulieren eruit zagen op een bepaalde dag in het verleden.

PVoutput


  • dingstje
  • Registratie: augustus 2002
  • Laatst online: 15-09 16:53
Zou je niet beter gewoon per betaalmethode een 'module' hebben, waarin je subclasses hebt van Zend_Form, waarin dan meteen de juiste validators zitten, en waarmee je meteen je business classes kan vullen? Door alles in een generieke database te stoppen, ga je ofwel snel tegen beperkingen aanlopen, ofwel toch nog een koppeling met specifieke modules moeten maken voor deelaspecten (validatie, verwerking, ...).

If you can't beat them, try harder



Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee