login  Naam:   Wachtwoord: 
Registreer je!
 Forum

Tekentafel afhandeling betaling (Opgelost)

Offline advertentiep - 28/04/2016 14:21 (laatste wijziging 28/04/2016 14:39)
Avatar van advertentiepPHP interesse Beste Leden,

Ik heb een overzicht gemaakt (sorry niet met software die hier bedoeld voor is), ik ga er vanuit dat de structuur duidelijk is.

https://symu.co/zrrrcj.sl

Wat jullie moeten weten over dit project. Het betreft een webwinkel welke wordt ontwikkeld voor de verkoop, code blijft in eigen beheer en word door mij gehost.

De beheerder
Ik probeer het zo in te richten dat de eigenaar (beheerder) alleen maar data hoeft in te voeren. Om de webwinkel te activeren dient de beheer minimaal 1 account te hebben bij sisow, targetpay en / of mollie.

De bezoeker
Bezoekt de webwinkel -> bekijkt een product (of niet) -> Voegt het product toe aan basket (of niet) -> Uitchecken (of niet) -> laatse fase systeem: controlles uitvoeren (opgehaalde data) en de betaling klaarzetten (data invoeren en data updaten (opgehaalde data)).

de webwinkel
Tabellen (relevant):

-winkelmand; houd alle toegevoegde producten 7 dagen vast gekoppeld aan IP.

- bestelling: record uit winkelmand met corresponderende ID gaat naar tabel bestelling met status 'open'.

de technieken
php 5 procedurele code structuur (sorry). en voor de betalingen wil ik deze schil gebruiken (credits @ Barry - fruitcake.nl) van THE PHP LEAGUE:
https://github.com/thephpleague/omnipay

Nogmaals ik heb geen ervaring met het afhandelen van betalingen alle suggesties en vraagtekens adhv van mijn blauwdruk (schets) is meer dan welkom.

https://symu.co/zrrrcj.sl (aanpassingen en comments kan je met een pin op het bestand plaatsen!

18 antwoorden

Gesponsorde links
Offline Thomas - 28/04/2016 14:42
Avatar van Thomas Moderator Wat is je vraag of waar heb je hulp bij nodig?

Citaat:
en voor de betalingen wil ik deze schil gebruiken (credits @ Barry - fruitcake.nl) van THE PHP LEAGUE.

Welke schil is dit? (link ontbreekt) Omnipay?

Dan denk ik dat je minimaal 3 tabellen nodig hebt voor het bijhouden van informatie omtrent bestellingen:

orders: kapstok voor orders
order_regels: de producten en aantallen en prijzen op het moment van bestelling
transacties: alle informatie over het doen van een betaling voor order X, bevat tevens de status van de betaling

Overigens kun je in een aantal losstaande scripts een betaalmethode testen in test-modus, dit kan los van andere (procedurele) code. Indien een betaalsite informatie terugstuurt naar jouw site dan moet dit laatste ook mogelijk zijn, oftewel, je testsite moet bereikbaar zijn via het internet, je kunt betaaloplossingen dan ook niet echt goed ontwikkelen vanaf je lokale machine ("localhost"). Het internet kent jouw "localhost" niet, tenzij deze niet achter een firewall zit (DMZ) of poorten doormapt en je een hostname hebt of een extern IP doorcommuniceert.

Omnipay gaat er ook prat op dat deze goed gedocumenteerd is, dus ik zou zeggen: lees en volg de handleiding - heb je dit al geprobeerd?
Offline advertentiep - 28/04/2016 14:52 (laatste wijziging 28/04/2016 14:54)
Avatar van advertentiep PHP interesse Thomas,

Link is toegevoegd. Mijn webwinkel staat online (testen is dus mogelijk - maar daar ben ik nog niet aan begonnen).

Waarom tabel order_regels en transacties niet samenvoegen ?

en voor de geïnteresseerde een link naar de uitgever met een aantal voorbeelden en instructies: http://omnipay.thephpleague.com/
Offline Thomas - 28/04/2016 15:47 (laatste wijziging 28/04/2016 15:48)
Avatar van Thomas Moderator
Citaat:
Waarom tabel order_regels en transacties niet samenvoegen ?

order_regels bevat informatie waar een order inhoudelijk uit bestaat.
Dit heeft niets te maken met de status/informatie van een (betalings)transactie.
Als er al een verband zou zijn tussen de twee dan is dit via de orders tabel (en dus niet de order_regels tabel).

Als je dit soort dingen modelleert kun je de volgende "truuk" gebruiken: identificeer de verschillende "spelers" (entiteiten) in je applicatie en schrijf de verbanden uit in lopende zinnen, bijvoorbeeld:

Een klant plaatst een order (bestelling).
Een order bestaat uit orderregels.
Een klant verricht na afloop een betaling(stransactie).
Een betaling(stransactie) hoort bij een order.
et cetera

Maak vervolgens een tekeningetje (diagram) waarbij je deze entiteiten uitschrijft en met elkaar verbindt via lijnen als hier een relatie tussen is. Je hebt dan een (zij het wat abstracte) specificatie voor je databasediagram.

Zorg er ook voor dat je de functionaliteit van een relationele database kunt gebruiken. Hiervoor moet je in MySQL gebruik maken van de InnoDB database-engine. Dit stelt je in staat om foreign keys en database-transacties (dit heeft niets met de transacties-tabel te maken overigens) kunt gebruiken zodat je administratieve data in een strak keurslijf komt te zitten waarmee je af kunt dwingen dat de data in deze tabellen consistent blijft.
Offline advertentiep - 29/04/2016 09:33 (laatste wijziging 29/04/2016 13:45)
Avatar van advertentiep PHP interesse
  1. Winkelmand Bestelling Betaling log
  2. ID (ai) != ID (niet ai) == ID (niet ai)== ID (niet ai)
  3. IP == IP == IP == (geen ip)
  4. status == status == status == status
  5. Bedrag != bedrag == bedrag == bedrag
  6. datum != datum == datum == datum


tab's komen er niet helemaal lekker uit. wat ik probeer te schetsen:

- winkelmand staat even los van de drie betaling relevante tabellen.

- Winkelmand is ID wel uniek (ai). De overige drie tabellen niet (denk ik?).
Het ID in de overige drie tabellen wordt overgenomen door winkelmand ID.

- De overige drie (bestelling (klaar zetten), betaling (betaling op zich) en log) zijn horizontaal gelijk (id, bedrag en status lopen parallel).

De overige drie tabellen worden aangevuld met specifieke velden:

tabel bestelling: aantal producten, kortingscode, totaal korting, adergegevens.
tabel betaling: unieke betaalcode, betaal methode, bank, creditcard gegevens.
tabel log: melding, nieuwsbrief.

is dit de truc ?

Na het lezen van: YAPF database ontwerp ga ik er nog even goed voor zitten.
Offline Thomas - 30/04/2016 13:28
Avatar van Thomas Moderator De tabel bestelling zou uiteen moeten vallen in wat jij beschrijft (kortingscode, totaalkorting, bedrag (ex of incl btw), factuur- en bezorgadres) maar alles wat over producten inhoudelijk gaat zou ik opnemen in een aparte tabel (de order_regels). "aantal producten" lijkt mij niet echt relevant? En als je dit nodig hebt is dit makkelijk afleidbaar uit de order_regels tabel. Productinformatie hoort ook in je database thuis lijkt mij. Je zou je winkelmand op kunnen slaan in je database, maar deze zou je ook (tijdelijk) kunnen bijhouden in iemands sessie?

Ik zou alle tabellen, behalve koppeltabellen wellicht, voorzien van een auto_increment veld. Dit geeft je namelijk altijd een middel om op een unieke manier aan een record te refereren.

Heb je trouwens ook nagedacht over de volgende zaken:
- voorraadbeheer, hoe zorg je ervoor dat men niet (veel) meer bestelt dan dat er op voorraad is?
- productinformatie (dit zal ook een beetje afhangen van de grootte van je assortiment) hoe zorg je ervoor dat je de producten makkelijk kunt zoeken en vinden in je webshop?

Als dit je eerste schreden zijn met betrekking tot database-ontwerp / het programmeren van een grote applicatie dan weet ik trouwens niet of dit de beste plaats is om hiermee te starten. Maar je kunt dit altijd proberen natuurlijk. Wel komen hier (webshop) een heleboel zaken bij elkaar.
Offline advertentiep - 30/04/2016 14:53
Avatar van advertentiep PHP interesse Het is iets wat groter geworden dan ik wilde. mijn idee was om een 1-product webwinkel te ontwikkelen. Maar ik hou het relatief klein.

Max 6 cat's (geen sub-cat!) en max 10 producten per cat. Ik denk dat mijn eventuele doelgroep winkeliers (fysieke) geen zin hebben om het hele assortiment aan te bieden. Op deze wijze hoeft ik bijvoorbeeld geen pagina-navigatie voor categorieën, geen fulltext search engine want alles is direct te navigeren vanuit de index etc.

Maar hoe ziet het volgende er dan uit:

Als een bezoeker wat in zijn winkelmand stopt (tabel: winkelmand ID + 1) maar vervolgens geen verdere actie onderneemt. Volgens jouw suggestie krijg je dan dus dat een volgende bezoeker die wat in zijn winkelmand stopt bijv het ID 10 heeft, en het corresponderende betaling ID 5 ?

Offline Thomas - 01/05/2016 00:23
Avatar van Thomas Moderator
Citaat:
Als een bezoeker wat in zijn winkelmand stopt (tabel: winkelmand ID + 1) maar vervolgens geen verdere actie onderneemt. Volgens jouw suggestie krijg je dan dus dat een volgende bezoeker die wat in zijn winkelmand stopt bijv het ID 10 heeft, en het corresponderende betaling ID 5 ?

Ik snap niet precies wat je hiermee bedoelt. Je zult op een of andere manier een gebruiker moeten identificeren en koppelen aan de winkelmand op het moment dat deze boodschappen in zijn winkelmandje doet als je deze winkelmanden in de database opslaat. Zoals ik het zie is de inhoud van een winkelmandje nogal tijdelijk van aard. Een sessie zou dan ook een geschiktere plaats zijn voor een winkelmand dan een database. Hoe houd je anders bij:
- of de inhoud van winkelmanden die in de database staan opgeslagen nog actueel is (hoop outdated rotzooi in je database? nein danke)
- van wie deze winkelmanden zijn, er moet dan een soort permanent verband zijn met een gebruiker, een koppeling via een sessie (die kan verlopen) gaat dan niet echt meer, je zou dan mensen eerst aan moeten sporen om een account te maken en in te loggen ofzo?

Ah well. Meerdere oplossingen mogelijk I suppose.
Offline advertentiep - 10/05/2016 13:54
Avatar van advertentiep PHP interesse Thomas,

Na een korte radio stilte heb ik vandaag Mollie succesvol geïntegreerd.

Het ziet er zo uit:
  1. index.php
  2. ../bezoekers/winkelmand (request-method=POST header naar betalen)
  3. ../bezoekers/betalen (header naar de betaalpagina (mollie)).
  4.  
  5. ../Toevoeging/Functies/Betaling/Mollie/API/betaling (haalt gegevens op (controleer) en header naar externe pagina van mollie).
  6.  
  7. ../Toevoeging/Functies/Betaling/Mollie/API/Webhoop (mollie bezoekt mij URL - update status betalling).
  8.  
  9. ../Toevoeging/Functies/Betaling/Mollie/API/return (bezoeker komt terug van betaalscherm) header naar /Bezoekers/ontvangen/id
  10.  
  11. ../bezoekers/ontvangen (hier weergeef ik de melding van betaling).


Enigsinds lastig was het feit dat ik toch IP gebonden ben gaan werken in mijn DB tabel en daar de gegevens permanent opsla, was even tricky om de scheiding te maken als mensen al betaalt hebben maar nog een keer iets bestellen.

enfin, alles werkt (in test modus) DB wordt netjes bijgewerkt, winkelmand wordt goed bijgewerkt.
Het enige wat niet werkt, klinkt heel lullig is het rekenwerk.

Ik las in jouw PHP variable tutorial dat niet elke float zich gedraagt zoals je zou verwachten.

Volgens mij is dat in mijn winkelwagen-afreken weergave hetzelfde probleem, de ene keer gaat het rekenen (plus, min, keer) wel goed, andere keer blijkbaar niet. Formaat van de bedragen is altijd 100.00 of 10000.00, ik laat de prijs met rust in de DB, voor de weergave gebruikt ik uiteraard number_format() maar ook als ik prijzen opsla in de DB zorg ik dat de prijzen "schoon" zijn.

webwinkel

Je kan producten toevoegen, zodra het bedrag niet rond is (op EUROs) dan zie je in de rechter kolom dat de cumulatieve prijs van de regel producten niet goed wordt verwerkt.

Enig idee ?
Offline Thomas - 11/05/2016 00:33 (laatste wijziging 11/05/2016 00:33)
Avatar van Thomas Moderator Dat kan ik zo niet zien aan de buitenkant.

Waarom sla je niet alles op in eurocenten (kun je integers gebruiken in plaats van floats)? Dan hoef je ook niets af te ronden. En het formatteren doe je dan met number_format() vlak voor het weergeven. Dan hoef je ook helemaal niets aan de bedragen aan te passen?
Offline advertentiep - 11/05/2016 15:09
Avatar van advertentiep PHP interesse Ik had ook gewoon een functie prijsWeergave en prijsInvoer moeten maken. Aangezien je best wel wat te maken hebt met bedragen in een webwinkel..stom.
Offline Thomas - 11/05/2016 16:24
Avatar van Thomas Moderator Afronden doe je ook pas helemaal aan het eind. Tussentijds afronden is een doodzonde.
Bedankt door: advertentiep
Offline advertentiep - 16/05/2016 14:13
Avatar van advertentiep PHP interesse zeer omslachtig maar opgelost (mochten mensen ooit nog zoeken):
  1. <?php
  2. function PrijsIngave ($iEuro, $iCent)
  3. {
  4. $fEuro = $iEuro * 100;
  5.  
  6. // Geen idee hoe je het aantal cijfers in een integer kan tellen
  7. $sTest = (string)$iCent;
  8.  
  9. // $cent = 2 moet twintig cent worden
  10. if (IsSet($sTest[0]) && !IsSet($sTest[1]))
  11. {
  12. $iCent = $sTest[0] . 0;
  13. }
  14. // Niks ingevuld dan moet 00 aan het einde toegevoegt worden
  15. if ($iCent == 0 || !IsSet($sTest[0]))
  16. {
  17. $iCent = .00;
  18. }
  19.  
  20. return $fEuro + $iCent;
  21.  
  22. }
  23.  
  24. function PrijsWeergave ($iPrijs)
  25. {
  26.  
  27. return $iPrijs / 100;
  28. }
  29.  
  30. function PrijsReken ($iPrijs, $iAantal, $sMethode)
  31. {
  32.  
  33. if ($sMethode == '+')
  34. {
  35. $iAantal = $iAantal * 100;
  36. return $iPrijs + $iAantal;
  37. }
  38. else
  39. {
  40. return $iPrijs * $iAantal;
  41. }
  42. }
  43.  
  44. $euro = 100;
  45. // zou dust 20 moeten worden
  46. $cent = 2;
  47.  
  48. $test = PrijsIngave($euro, $cent);
  49. $test2 = PrijsReken ($test, 3, '*');
  50. echo number_format(PrijsWeergave($test2), 2, ',', '.');
  51.  
  52. // output: 300,60
  53. ?>
Offline Thomas - 16/05/2016 14:26 (laatste wijziging 16/05/2016 14:28)
Avatar van Thomas Moderator
Thomas schreef:
Waarom sla je niet alles op in eurocenten? ... Dan hoef je ook helemaal niets aan de bedragen aan te passen?

  1. <?php
  2. $bedrag = 10002; // 100 euro, 2 cent, oftewel 10002 eurocenten
  3.  
  4. // een functie voor het formatteren van een bedrag is wellicht wel handig
  5. function formatBedrag($in) {
  6. // alleen bij WEERGAVE deel je door 100
  7. return number_format($in/100, 2, ',', '.');
  8. }
  9.  
  10. $som = $bedrag * 3; // niks geen lastige functies, gewoon rekenen in PHP
  11.  
  12. echo formatBedrag($som);
  13. ?>

Ik denk dat je het wiel een beetje opnieuw aan het uitvinden bent met jouw functies.
Offline advertentiep - 16/05/2016 14:35 (laatste wijziging 16/05/2016 14:47)
Avatar van advertentiep PHP interesse Ik ga alles opslaan in centen, echter wilde ik wel testen alvorens het implementeren van eurocenten. Er zijn twee velden:

[tekstveld 1 - euros] , [tekstveld 2 - eurocenten]

als men niks invult bij eurocenten (tweede parameter) wil ik dat deze wel wordt aangevuld met 00.
als men 100,5 invult wil ik dat het 100,50 wordt.

Tevens stoorde ik mij aan de ouput welke ik genereerde, vaak werd het: 100,7 en ik wil 100,70 hebben.

EDIT; je kan toch ook zien dat ik in centen werkt / 100 * 100 ?
Offline Thomas - 16/05/2016 23:12
Avatar van Thomas Moderator Die twee velden kun je toch ook combineren bij opslag en weer uit elkaar trekken bij weergave (in een formulier)?

Om er mee te kunnen rekenen / om deze waarden op te slaan heb je toch echt maar één getal / één kolom nodig.
Offline advertentiep - 17/05/2016 08:46
Avatar van advertentiep PHP interesse Dat is ook om te voorkomen dat dat mensen een , . of ,- invoeren.
Op deze wijze kan ik alles duidelijk weg zetten en weergeven.
Offline Jointjeff - 17/05/2016 10:38
Avatar van Jointjeff HTML interesse Dat kun je ook nog opvangen door enkel numerieke-invoer te accepteren.
Offline Thomas - 17/05/2016 14:53 (laatste wijziging 17/05/2016 14:56)
Avatar van Thomas Moderator Inderdaad, wat @JointJeff zegt, dat kun je op een andere plaats en manier oplossen. Dat zou niet tot gevolg moeten hebben dat dit je hele dataset in een bepaalde weergavevorm dwingt waarmee je alleen op een uiterst onhandige manier mee kunt rekenen...

Zoals ik al aangaf, als iemand een bedrag moet invoeren kun je dit desnoods splitsen in twee aparte formuliervelden (euro's en centen). Wanneer je deze data submit maak je hier één bedrag van (in eurocenten):

bedrag = euro's * 100 + centen

Overigens als je verder wilt discussiëren over dit topic, verwijder dan svp de opgelost-markering via het oorspronkelijke bericht.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Actieve forumberichten
© 2002-2024 Sitemasters.be - Regels - Laadtijd: 0.228s