Paypal - Status lekérdezés (ExpressCheckout)
Sziasztok!
Néztem, hogy 1-2 alkalommal volt már téma a paypal fizetés de nem kaptam választ a kérdésemre.
Egy összetettebb oldalra szeretnék paypal fizetést.
Nem simán egy gombos fizetés lenne, hanem Reference Transactions típusú.
Ugyanezt az OTP-nél már megcsináltuk, és elvileg félig meddig működik a paypal-nál is amit az SDK alapján csináltunk.
A folyamat ahol elakadtunk úgy néz ki (SDK példa):
1. SetExpressCheckout - itt beállítjuk a fizetés paramétereit és az egyebeket
2. a kapott URL-re eljut az ügyfél, ahol belép és elfogadja a fizetés és a szeződést
3. az ügyfél visszajut az oldalunkra
4. GetTransactionDetails - itt lekérdezzük az ügyfél adatait
5. DoExpressCheckoutPayment - itt ezzel jóváhagyjuk a fizetést mi is.
4.b. Ha cancelt nyomott akkor egy másik cím hívódik meg, és a 4. és 5. pont nem fut le.
(tehát a fizetés attól is függ, hogy az ügyfél hova jutott)
Az alapvető probléma, hogy a példa szerint sikeres fizetés esetén a returnURL hívódik meg. Egyéb esetben meg a CancelURL.
Nálunk az a baj, hogy a weboldal és a fizetési rendszer nem egy helyen van. Így az ügyfelet nem tudjuk a fizetési rendszer egy oldalára küldeni, és egyéb okok miatt nem is lenne nálunk szerencsés ha egy böngészőtől függne lezárul -e a tranzakció.
Az OTP esetén úgy kellett csinálni, hogy beállítottuk a fizetést, az ügyfél eljutott az OTP felületére, ott fizetett és valahova visszatért. A háttérben pedig a fizetési rendszerünk folyamatosan elkezdte a tranzakció állapotát lekérdezgetni. Tehát láttuk ha még az ügyfélre várunk, vagy befejezte a fizetést (akár sikeresen akár nem).
Hasonlót kellene itt is megvalósítanunk.
Az 1-3 pont az tejesíti is a dolgot. Sőt a 4-5 pont is jó lenne (GetTransactionDetails-el lekérdezgetjük a tranzakciót, és ha rendben van, akkor DoExpressCheckoutPayment-el lezárjuk).
Sajnos a GetTransactionDetails csak akkor arról ad választ nekünk, hogy sikeres volt -e a vásárlás. Ez sajnos kevés, mert amennyiben az ügyfél pl. cancel-t nyomott, akkor a paypal lezárja a tranzakciót, de mi viszont erről nem fogunk értesülni. Nem tudjuk, hogy még mojol az ügyfél, bezárta az oldalt, vagy netán cancel-el elutasította a dolgot.
Próbáltuk azt is, hogy állítunk be IPN címet az oldalon (pl. az lehetne ami elindítaná a 4. és 5. pontot). Ott semmit nem csináltunk csak annyit, hogy ha meghívódik, akkor a $_GET, $_POST, $_REQUEST és $_SERVER tömböket lementettük fájlba (tehát nem csináltuk még meg a visszahívást sem még).
Az IPN szimulátorban szépen működött is a dolog, de ha próbavásárlást csináltunk, akkor a Paypal csak akkor hívott meg minket amikor sikeres volt a vásárlás. (az IPN history szerint sem volt több küldés) Pedig IPN-nél mindenhol oldassuk, hogy minden fajta állapotot ki kéne tudnunk olvasni.
A kérdésem, hogy vagy az IPN-en hogy lehetne elérni, hogy megkapunk minden állapotot és ne csak a sikeres fizetést?
Vagy a GetTransactionDetails-ből hogy lehetne kiszedni hogy cancel-el nem -e már rég lezáródott a tranzakció.
Vagy milyen más módszerrel lehetne lekérdezni a paypal-tól, hogy az ügyfél rányomott e már a vásárlásra, és el lehet -e kezdeni a DoExpressCheckoutPayment lezárást.
ui: Mint írtam az ügyfél nem tud oda ugrani ahol a 4. 5. pont scriptjei vannak, és ha lehet kerülnék, hogy ahova az ügyfél kerül az az oldal próbáljon akkor bejutni indulhat a fizetés. Úgy ahogy az OTP esetén is kerülve volt (ahogy kérték ne pusztán a böngészőre támaszkodjunk), hogy az ügyfél böngészőjén múljon befejeződik/feldolgozódik -e a tranzakció vagy sem.
Előre is köszönöm a segítséget.
Zoli
■ Néztem, hogy 1-2 alkalommal volt már téma a paypal fizetés de nem kaptam választ a kérdésemre.
Egy összetettebb oldalra szeretnék paypal fizetést.
Nem simán egy gombos fizetés lenne, hanem Reference Transactions típusú.
Ugyanezt az OTP-nél már megcsináltuk, és elvileg félig meddig működik a paypal-nál is amit az SDK alapján csináltunk.
A folyamat ahol elakadtunk úgy néz ki (SDK példa):
1. SetExpressCheckout - itt beállítjuk a fizetés paramétereit és az egyebeket
2. a kapott URL-re eljut az ügyfél, ahol belép és elfogadja a fizetés és a szeződést
3. az ügyfél visszajut az oldalunkra
4. GetTransactionDetails - itt lekérdezzük az ügyfél adatait
5. DoExpressCheckoutPayment - itt ezzel jóváhagyjuk a fizetést mi is.
4.b. Ha cancelt nyomott akkor egy másik cím hívódik meg, és a 4. és 5. pont nem fut le.
(tehát a fizetés attól is függ, hogy az ügyfél hova jutott)
Az alapvető probléma, hogy a példa szerint sikeres fizetés esetén a returnURL hívódik meg. Egyéb esetben meg a CancelURL.
Nálunk az a baj, hogy a weboldal és a fizetési rendszer nem egy helyen van. Így az ügyfelet nem tudjuk a fizetési rendszer egy oldalára küldeni, és egyéb okok miatt nem is lenne nálunk szerencsés ha egy böngészőtől függne lezárul -e a tranzakció.
Az OTP esetén úgy kellett csinálni, hogy beállítottuk a fizetést, az ügyfél eljutott az OTP felületére, ott fizetett és valahova visszatért. A háttérben pedig a fizetési rendszerünk folyamatosan elkezdte a tranzakció állapotát lekérdezgetni. Tehát láttuk ha még az ügyfélre várunk, vagy befejezte a fizetést (akár sikeresen akár nem).
Hasonlót kellene itt is megvalósítanunk.
Az 1-3 pont az tejesíti is a dolgot. Sőt a 4-5 pont is jó lenne (GetTransactionDetails-el lekérdezgetjük a tranzakciót, és ha rendben van, akkor DoExpressCheckoutPayment-el lezárjuk).
Sajnos a GetTransactionDetails csak akkor arról ad választ nekünk, hogy sikeres volt -e a vásárlás. Ez sajnos kevés, mert amennyiben az ügyfél pl. cancel-t nyomott, akkor a paypal lezárja a tranzakciót, de mi viszont erről nem fogunk értesülni. Nem tudjuk, hogy még mojol az ügyfél, bezárta az oldalt, vagy netán cancel-el elutasította a dolgot.
Próbáltuk azt is, hogy állítunk be IPN címet az oldalon (pl. az lehetne ami elindítaná a 4. és 5. pontot). Ott semmit nem csináltunk csak annyit, hogy ha meghívódik, akkor a $_GET, $_POST, $_REQUEST és $_SERVER tömböket lementettük fájlba (tehát nem csináltuk még meg a visszahívást sem még).
Az IPN szimulátorban szépen működött is a dolog, de ha próbavásárlást csináltunk, akkor a Paypal csak akkor hívott meg minket amikor sikeres volt a vásárlás. (az IPN history szerint sem volt több küldés) Pedig IPN-nél mindenhol oldassuk, hogy minden fajta állapotot ki kéne tudnunk olvasni.
A kérdésem, hogy vagy az IPN-en hogy lehetne elérni, hogy megkapunk minden állapotot és ne csak a sikeres fizetést?
Vagy a GetTransactionDetails-ből hogy lehetne kiszedni hogy cancel-el nem -e már rég lezáródott a tranzakció.
Vagy milyen más módszerrel lehetne lekérdezni a paypal-tól, hogy az ügyfél rányomott e már a vásárlásra, és el lehet -e kezdeni a DoExpressCheckoutPayment lezárást.
ui: Mint írtam az ügyfél nem tud oda ugrani ahol a 4. 5. pont scriptjei vannak, és ha lehet kerülnék, hogy ahova az ügyfél kerül az az oldal próbáljon akkor bejutni indulhat a fizetés. Úgy ahogy az OTP esetén is kerülve volt (ahogy kérték ne pusztán a böngészőre támaszkodjunk), hogy az ügyfél böngészőjén múljon befejeződik/feldolgozódik -e a tranzakció vagy sem.
Előre is köszönöm a segítséget.
Zoli
Nem megy
Ez az egesz azert lesz biztonsagos, mert amig a DoExpressCheckoutPayment hivas nem tortenik meg, az ugyfel kartyaja nem terhelodik, ellentetben az OTP-vel, ami az o oldalukon torteno gombnyomas hatasara azonnal terhel.
A legkezenfekvobb megoldas az, hogy beraksz egy icipici loading screent ami a hatterben lekerdezi a PayPalt, majd utana a tovabb dobod a usert a shop "thank you" oldalara.
Arra is figyelj, hogy ha a usert nem commit parameterrel dobod at, akkor a leiras szerint a vegen meg mutatnod kell egy osszesito screent mielott a terhelest elvegzed. Ezt elkerulendo a webscr URL-nek add at a useraction=commit parametert.
Szia köszi.Tehát itt attól
Tehát itt attól függhet csak a végrehajtás, hogy az ügyfél visszajutott -e hozzánk.
Bár az IPN-nél az volt az érdekes, hogy minden féle teszt üzenetet lehetett küldeni, hogy az ügyfél elutasította, meg már gárakozik, stb.
Akkor ezek mikor jönnének?
A mi esetünkben úgy van felépítve:
1. ügyfél kér fizetést az oldalon
2. az oldal beküldi a fizetési rendszerünknek a kérést, az kommunikál a paypalel, elmenti amit kell, és visszakapja az oldal az URL-t amit meg kell nyitni az ügyfélnek.
3. az oldal fogadja a választ, és az ügyfelet egy minibrowserben elirányítja a paypal-ra.
4. ott az ügyfél elintézi az azonosítást, és az elfogadást.
5. az ügyfél visszajut a return vagy cancel url-re ami a weboldalunkon van (ez pár másodperc után bezárul).
(Eddig ugye megegyezik az OTP-vel...)
6. Akkor annak a return oldalnak kéne beküldeni ismételt a fizetési rendszernek, hogy attól füg hova érkezett az ügyfél vagy zárja le a fizetést sikertelenül, vagy do-val fejezze be a fizetést.
7. A fizetési rendszer visszaüzen a weboldalnak.
8. A weboldal pedig jóváírja azt amit jóvá kell írni.
Sajnálom ha így megy, mert ha a lekérdezést is egy böngészőn keresztül kell meglökni a fizetés véglegesítését.
Azért bíztunk tényleg az IPN-ben, mert ott a példák szerint minden féle dolgot visszaadna. Ha én azért hajtom végre a DoExpressCheckoutPayment-et, mert az ügyfél visszajutott a return URL-re, akkor ott már igazából soha nem jelenhetnek meg ezek hogy az ügyfél elutasította a vásárlást cancellel, stb.
Kérdésem, hogy azt hogy lehet beállítani, hogy mennyi ideig éljen a vásárlási link? Mintha órák múlva is meg lehetne nyitni még. Nekünk viszont nem szerencsés ha valami ilyen sokáig függőben van. Be lehet állítani, hogy mondjuk 5-10 perce legyen csak befejezni a fizetést?
A másik, hogy a SetExpressCheckout-nál meállítom mit és mennyit szeretnék fizettetni. Ez jelenik meg az ügyfélnek, viszont a DoExpressCheckoutPayment-nál újra ezt be kell állítni, és itt tudunk már teljesen mást is írni. Ez miért jó? (csak újabb hibalehetőség)
És lehet ehhez kapcsolódik az amit írtál és nem tejesen étettem:
"Arra is figyelj, hogy ha a usert nem commit parameterrel dobod at"
IPN kihagyható amúgy? Elegendő a DoExpressCheckoutPayment figyelése, hogy sikeres volt -e? Mert akkor ezek szerint ezt csak egyszer kell megpróbálni végrehajtani. Ha sikeres volt akkor minden rendben, ha nem, akkor nem akkor valami nem várt hiba volt.
Illetve:
"Arra is figyelj, hogy siman visszajohet az, hogy a payment pending es ujra varakoznod kell."
Itt arra gondolsz, hogy a DoExpressCheckoutPayment -re kaphatok ilyen választ? És ha ilyen jön, akkor úja kell küldenem a DoExpressCheckoutPayment-et kicsit később? Vagy a GetTransactionDetails -el le kell kérdezti újra, hogy akkor mi van? Vagy mire gondoltál?
Do
Nem tudom, hogy van-e timelimit a PayPal oldalan, de alapvetoen az Neked ne fajjon, ha a tranzakcio fuggoben marad. PayPalnal legalabbis ne. OTP-nel tudom, hogy ez problema, ott idonkent le kell kerdezni a pollozo modszerrel, hogy megjott-e mar. Egy normalisan mukodo rendszerben mindig is lesznek fuggo fizeteseid, ezeket vagy lezarod sikertelennel mondjuk egy nap utan, vagy elgondolkodsz hogy mit akarsz vele csinalni. Ha kesobb megis bejon a penz, akkor jova kell irni a usernek.
A DoExpressCheckoutPaymentnel meg atallithatod, de nem tudom, hogy pl. folfele tudod-e allitani. Akkor lehet hasznos, ha a userrol kozben kiderul, hogy pl. jogosult kisebb AFA-ra.
Itt arra gondolsz, hogy a DoExpressCheckoutPayment -re kaphatok ilyen választ? És ha ilyen jön, akkor úja kell küldenem a DoExpressCheckoutPayment-et kicsit később? Vagy a GetTransactionDetails -el le kell kérdezti újra, hogy akkor mi van? Vagy mire gondoltál?
Ilyenkor ujabb GetTransactionDEtailst vagy mi a szoszt kell futtatnod.
Köszi. Az elsőre az jutott
Az elsőre az jutott eszembe mikor olvastam a válaszodat:
Nem az a bajom hogy úgy marad, hanem hogy a kosarat meddig tartogassam neki. De mivel én zárom a tranzakciót, és úgy néz ki meg kell lökni az ügyféllel ezt a metódust, ezért megcsinálhatom, hogy én a saját adatbázisomban lezárom a tranzakciót, és ha fizet, akkor hibát írok ki, és nem hajtom végre a DoExpressCheckoutPayment-et.
2. Nem emlékszem mit próbáltunk. De arra igen, hogy símán át tudtuk akár a vásárolt termék nevét is írni. Így ha gonoszkodji akrjénk, akkor azt mondom veszel egy DVD lejátszót, de a számládon az fog szerepelni hogy egy mosószivacsot vettél 10.000Ft-ért. És bizonyítsd be mi volt a képernyőre kiírva. Ha meg akarod nézni a paypal oldalán ott lesz fehéren feketén, hogy te szivacsot vettél.
3.A hivatalos példa szerint előbb a GetTransactionDetails-et hívják meg (mert kell belőle ügyféladat), majd a DoExpressCheckoutPayment-et. Ezek szerint ha azt kapom, hogy várjak, akkor GetTransactionDetails-el kell újra kérdeznem mi is van. Nem lehet ez valahogy előidézni, hogy ne csak megérzésre írjuk a kódot, hanem az ezen szituációra valóban így is viselkedjen? Pl. pontosan milyen üzenet jőn, jöhet -e ilyen az ismételt lekérdezésre, stb.
Vagy esetleg már az első GetTransactionDetails-re is jöhet ilyen, és magát a DoExpressCheckoutPayment-et kell addig elhúzni, míg a GET már nem at zöld utat?
És ez még mindig érdekelne:"nem commit parameterrel dobod at"
Itt mire gondolsz? Amikor tokennel átirányítom az ügyfelet az Paypal oldalra bejelentkezni? Ott az SDK-s példa nem ad az ügyfélnek commit paramétert. Az infók valahol a háttérben mennek be (nem fejtettük vissza mit és hol küld be)
Kosar
2. Siman atirhatsz mindent, de ugye a PayPal loggolja es ha disputenal az derul ki, hogy nem azt csinaltad amit igertel, vagy ami megfelel a szabalyoknak, viharos sebesseggel veszted el a PayPal accountodat.
3. Sajnos ez nincs jol ledokumentalva, de az API-ban benne van, hogy a DoExpressCheckoutPayment-nel johet vissza pending, ergo erre fel kell keszulnod.
4. Innen idezek https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECCustomizing/
Köszi. Sokat segítesz. 1.
Sokat segítesz.
1. Nem arról van szó, hogy nem tudom odaadni a terméket, mert az digitális. Ezért pl. kreditet tud venni, de a kredit vásárlás összekapcsolódhat egyben már kreditfelhasználással is (valamit igénybe vett az ügyfél, és az rögtön le is kerül vonásra a kreditekből). Azért nem szeretnénk hosszú ideig elhúzni, mert mondjuk egy 3 óra múlva rányom a vásárlásra, és befejezni, akkor a vásárolt kreditekből már nem lenne szerencsés, ha levonódnának a kreditek, mert vélhetőleg azt már nem kívánja igénybe venni.
(Persze ez is csak elmélet és nem életszerű, de fontos a az egységes és érthető kommunikáció).
2. Nem kívánunk átírni semmit, csak így elsőre kicsit érthetetlennek tűnt, hogy miért jó ez. Mert értem én, hogy arra jó, ha a fizetés közben kiderülne (mert csak a paypalra bízok mindent) hogy pl. valami kedvezménye lenne, vagy stb. akkor tudnék még módosítani, de szerintem akkor sem ártana egy ügyfélnek tudni róla, hogy mégis mást fog fizetni. És ebben nem látom a biztosítékot, hogy egy kereskedő ezt meg is tett -e, ha eddig is a paypal-al akart minden elintéztetni.
3. Sajnos kor minden ne, vagy egymásnak ellentmondóan van dokumentálva. Sőt még az SDK-ben is volt hiba, mert volt ami nem indult el. (Persze más fizetési módok esetén is sorra találtunk hibákat eddig, tehát ez utóbbi nem lóg ki a sorból.)
4. Szerintem ezt az SDK küldés elintézni, mert jó a kiírás, sőt a mi esetünkben további feliratok is szükségesek.
Miert jo
Ami a kosarat illeti, PayPalnel kb 5 percig el a sessionod ha jol emlekszem, utana ugyis ujra kell csinalni mindent, szoval ne felj ettol.
IPN
Én a Cancel státust erre nem alapoznám... Mi van, ha eljut a PP oldalára, amjd bezárja a böngészőt. Ekkor nem történik semmilyen request ami kiváltana bárhol bármit.
Neked kell fenntartani a rendelés állapotait. Elmenteni pl a tényt (időbélyeg kíséretében), hogy elkülded a fizető felületre. Ha később érdeklődik az ügyfél (a ti oldalatok "rendeléseim" menüpontjában) ott egy logika eldöntheti (X idő elteltével) hogy a fizetéssel gondok voltak, és felajánlhatja az újboli fizetést, vagy az ügyfélszolgálat elérését (ha az ügyfél úgy gondolja, hogy a tranzakció megtörtént).
Köszi neked is a
Minden le van logolva le van tárolva, ezzel nincs gond, de mint fent írtam üzleti döntés és ügyfélvédelem miatt ugyanúgy mint az összes többi fizetésnél itt sem szeretnénk ha egy hosszú órákra, napokra (adaptive módban úgy emlékszem ilyen is volt) nyitva hagyott fizetési ablakot még lehessen folytatni.
Természetesen az igaz, hogy becsukhatja az ügyfél az ablakot, de ha úgy működött volna mint pl egy OTP, akkor X perc után TIMEOUT-ra futna, és akkor mi is le tudnánk zárni a tranzakciót.
De ha tudnánk, hogy cancelt nyomott (amúgy ahogy ezt a paypal tudja), akkor ere rögtön tudtunk volna reagálni (akkor is ha az ügyfél böngészője az átirányítás közben behal).
Próbáltunk hasonló kialakítást kialakítani mindenhol, mert a másik 4 fizetési módnál ez tökéletes (sőt sok esetben elvárt) működés.
Zoli
Gondolom arra gondolsz, hogy
Ezt valóban nem néztem.
De ha az eredeti linkre még rendelkezésre áll (.....?token=XXXX) valahonnan (history, back, stb.), akkor az nekünk jóval később is működött még.
Egy másik helyen meséltek valami tranzakció timeoutról, de végül nem tudták megmondani mivel is állítható.