[php/mysql] Koppeling tussen betaalmethode en zijn opties

[ReenL]

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]

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]

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]

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.

[dingstje]

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, ...).