A PayPal 11 éves API-katasztrófája: Hogyan dolgoztunk ki kerülő megoldásokat, miközben ők figyelmen kívül hagyták a fejlesztőket
A Forward Emailnél több mint egy évtizede küzdünk a PayPal hibás API-jaival. Ami apró frusztrációként indult, az teljes katasztrófává fajult, ami arra kényszerített minket, hogy saját megoldásokat dolgozzunk ki, blokkoljuk az adathalász sablonokat, és végül leállítsuk az összes PayPal-fizetést egy kritikus fiókmigráció során.
Ez a PayPal 11 évének története, amely során figyelmen kívül hagyta az alapvető fejlesztői igényeket, miközben mi mindent megpróbáltunk, hogy a platformjuk működjön.
A hiányzó rész: Nincs mód az előfizetések listázására
Ami viszont megdöbbentő: a PayPal 2014 óta számláz előfizetések alapján, de soha nem biztosítottak lehetőséget a kereskedőknek arra, hogy listázzák a saját előfizetéseiket.
Gondolkozz el ezen egy pillanatra. Létrehozhatsz előfizetéseket, lemondhatod őket, ha megvan az azonosítód, de nem kaphatod meg a fiókodhoz tartozó összes aktív előfizetés listáját. Olyan ez, mintha egy adatbázisod lenne SELECT utasítás nélkül.
Az alapvető üzleti műveletekhez erre van szükségünk:
- Ügyfélszolgálat (amikor valaki e-mailben érdeklődik az előfizetésével kapcsolatban)
- Pénzügyi jelentések és egyeztetés
- Automatizált számlázáskezelés
- Megfelelőség és auditálás
De a PayPal? Egyszerűen... sosem fejlesztették ki.
2014-2017: Felmerül a probléma
Az előfizetési listázással kapcsolatos probléma először a PayPal közösségi fórumain jelent meg 2017-ben. A fejlesztők a nyilvánvaló kérdést tették fel: „Hogyan kaphatom meg az összes előfizetésem listáját?”
A PayPal válasza? Tücskök.
A közösség tagjai elkezdtek frusztráltak lenni:
„Nagyon furcsa mulasztás, ha egy kereskedő nem tudja listázni az összes aktív megállapodást. Ha a megállapodás azonosítója elveszik, az azt jelenti, hogy csak a felhasználó mondhatja le vagy függesztheti fel a megállapodást.” - leafspider
„+1. Majdnem 3 éve történt.” - laudukang (ami azt jelenti, hogy a probléma ~2014 óta fennáll)
A 2017-es eredeti közösségi bejegyzés azt mutatja, hogy a fejlesztők könyörögnek ezért az alapvető funkcióért. A PayPal válasza az volt, hogy archiválta azt a tárhelyet, ahol az emberek jelentették a problémát.
2020: Kiterjedt visszajelzést adunk nekik
2020 októberében a PayPal megkeresett minket egy hivatalos visszajelzési megbeszélés keretében. Ez nem egy kötetlen beszélgetés volt – egy 45 perces Microsoft Teams hívást szerveztek 8 PayPal-vezetővel, köztük Sri Shivanandával (műszaki igazgató), Edwin Aokival, Jim Magatsszal, John Kunzéval és másokkal.
A 27 elemből álló visszajelzési lista
Felkészülten érkeztünk. Miután 6 órát próbálkoztunk az API-jaik integrációjával, 27 konkrét problémát gyűjtöttünk össze. Mark Stuart, a PayPal Checkout csapatától, ezt mondta:
Szia Nick, köszönöm, hogy megosztottad ma mindenkivel! Szerintem ez katalizátorként szolgál majd ahhoz, hogy a csapatunk további támogatást és befektetést kapjon, hogy megoldhassuk ezeket a problémákat. Nehéz volt ilyen tartalmas visszajelzéseket kapni, mint amilyeneket eddig hagytál nekünk.
A visszajelzés nem elméleti jellegű volt – valós integrációs kísérletekből származott:
- A hozzáférési token generálása nem működik:
A hozzáférési tokenek generálása nem működik. Ezenkívül nem csak cURL példáknak kellene lenniük.
- Nincs webes felhasználói felület az előfizetés létrehozásához:
Hogy a csudába lehet előfizetéseket létrehozni anélkül, hogy cURL-t kellene használnod? Úgy tűnik, nincs webes felhasználói felület ehhez (mint a Stripe-nak).
Mark Stuart a hozzáférési token problémáját különösen aggasztónak találta:
Általában nem hallunk problémákról a hozzáférési tokenek generálásával kapcsolatban.
Csapatok vettek részt, ígéretek hangzottak el
Ahogy egyre több problémát fedeztünk fel, a PayPal egyre több csapatot vett fel a beszélgetésbe. Darshan Raju, az Előfizetések kezelési felhasználói felületének csapatától csatlakozott, és a következőket mondta:
Ismerd el a hiányosságot. Nyomon követjük és orvosoljuk. Köszönjük a visszajelzést!
A foglalkozás leírása szerint a következőket keresték:
őszinte beszámoló a tapasztalataidról
hogy:
a PayPalt olyanná kell tenni, amilyennek a fejlesztők számára lennie kellene.
Az eredmény? Semmi.
A hivatalos visszajelzési ülés, a kiterjedt, 27 elemből álló lista, a több csapat bevonása és az ígéretek ellenére, amelyek a következőkre vonatkoznak:
követés és cím
problémák, abszolút semmi sem lett megoldva.
A vezetői exodus: Hogyan veszítette el a PayPal az összes intézményi emlékezetét
És itt jön be igazán az érdekesség. Mindenki, aki megkapta a 2020-as visszajelzésünket, elhagyta a PayPalt:
Vezetői változások:
- Dan Schulman (vezérigazgató 9 évig) → Alex Chriss (2023. szeptember)
- Sri Shivananda (a visszajelzéseket szervező műszaki igazgató) → JPMorgan Chase (2024. január)
Műszaki vezetők, akik ígéreteket tettek, majd távoztak:
- Mark Stuart (az ígért visszajelzés „katalizátorként” fog szolgálni) → IDEIGLENES_PLACEHOLDER_0
- Jim Magats (18 éves PayPal-veterán) → IDEIGLENES_PLACEHOLDER_1 (2022)
- John Kunze (globális fogyasztási cikkekért felelős alelnök) → IDEIGLENES_PLACEHOLDER_2 (2023)
- Edwin Aoki (az utolsók egyike) → IDEIGLENES_PLACEHOLDER_3 (2025. január)
A PayPal egy forgóajtóvá vált, ahol a vezetők fejlesztői visszajelzéseket gyűjtenek, ígéreteket tesznek, majd jobb cégekhez, például a JPMorganhoz, a Ripple-höz és más fintech cégekhez távoznak.
Ez magyarázza, hogy a 2025-ös GitHub-problémára adott válasz miért tűnt teljesen függetlennek a 2020-as visszajelzésünktől – szó szerint mindenki, aki megkapta ezt a visszajelzést, elhagyta a PayPalt.
2025: Új vezetés, ugyanazok a problémák
Ha előreugrunk 2025-re, pontosan ugyanaz a minta rajzolódik ki. Évekig tartó előrelépés nélkül a PayPal új vezetése ismét kapcsolatba lépett.
Az új vezérigazgató bekapcsolódik
- június 30-án közvetlenül a PayPal új vezérigazgatójához, Alex Chrisshez fordultunk az ügyben. Válasza rövid volt:
Szia Nick! – Köszönöm a hozzászólásodat és a visszajelzést. Michelle (cc'd) a csapatával együtt készen áll arra, hogy együttműködjenek veled és megbeszéljék ezt. Köszönöm -A
Michelle Gill válasza
Michelle Gill, a Kisvállalkozásokért és Pénzügyi Szolgáltatásokért felelős alelnök és vezérigazgató így válaszolt:
Nagyon szépen köszönöm Nick, Alexet áthelyeztem a titkos másolat csoportba. Az előző bejegyzésed óta vizsgáljuk ezt az ügyet. Még a hét vége előtt felhívunk. Elküldenéd nekem az elérhetőségeidet, hogy az egyik kollégám felvehesse veled a kapcsolatot? Michelle
Válaszunk: Nincs több megbeszélés
Elutasítottunk egy újabb találkozót, a következőképpen magyarázva csalódottságunkat:
Köszönöm. Azonban nem érzem úgy, hogy egy telefonhívás bármit is eredményezne. Íme, miért... Korábban már felhívtam, és az sehová sem vezetett. Több mint 2 órát pazaroltam arra, hogy az egész csapattal és a vezetőséggel beszéljek, és semmi sem történt... Rengeteg e-mail oda-vissza. Semmi sem történt. A visszajelzések sehová sem vezettek. Évekig próbálkoztam, meghallgattak, és aztán sehová sem jutottam.
Marty Brodbeck túlmérnöki válasza
Aztán Marty Brodbeck, a PayPal fogyasztói mérnöki részlegének vezetője megkereste:
Szia Nick, Marty Brodbeck vagyok. Én vezetem a PayPal fogyasztói mérnöki feladatait, és én irányítottam a cég API-fejlesztését. Meg tudnánk beszélni veled és velem, hogy milyen problémával szembesülsz, és hogyan segíthetünk?
Amikor elmagyaráztuk az előfizetési listázási végpont egyszerű szükségességét, a válasza feltárta a pontos problémát:
Köszönöm Nick, éppen egy egyetlen előfizetési API létrehozásán dolgozunk teljes SDK-val (teljes hibakezelést, eseményalapú előfizetés-követést és robusztus üzemidőt támogat), ahol a számlázás is külön API-ként van szétválasztva, hogy a kereskedők a válaszadáshoz ne kelljen több végponton keresztül koordinálniuk a folyamatot.
Ez pontosan a rossz megközelítés. Nincs szükségünk hónapokig tartó komplex architektúrára. Egyetlen egyszerű REST végpontra van szükségünk, amely listázza az előfizetéseket – valami olyasmire, aminek már 2014 óta léteznie kellett volna.
GET /v1/billing/subscriptions
Authorization: Bearer {access_token}
Az „Egyszerű CRUD” ellentmondás
Amikor rámutattunk, hogy ez egy alapvető CRUD funkció, amelynek már 2014 óta léteznie kellett volna, Marty válasza sokatmondó volt:
Az egyszerű Crud műveletek az alap API részét képezik barátom, szóval nem fog hónapokig tartó fejlesztést igényelni.
A PayPal TypeScript SDK, amely hónapokig tartó fejlesztés után jelenleg csak három végpontot támogat, a korábbi idővonalával együtt egyértelműen azt mutatja, hogy az ilyen projektek befejezése több hónapot vesz igénybe.
Ez a válasz azt mutatja, hogy nem érti a saját API-ját. Ha „az egyszerű CRUD műveletek az alap API részét képezik”, akkor hol van az előfizetési lista végpontja? Válaszoltunk:
Ha „az egyszerű CRUD műveletek az alapvető API részét képezik”, akkor hol van az előfizetési listázási végpont? A fejlesztők 2014 óta kérik ezt az „egyszerű CRUD műveletet”. Már 11 éve. Minden más fizetési processzor az első naptól kezdve rendelkezett ezzel az alapvető funkcióval.
A kapcsolat megszakadása egyértelművé válik
A 2025-ös Alex Chriss, Michelle Gill és Marty Brodbeck közötti eszmecserék ugyanazt a szervezeti működési zavart mutatják:
- Az új vezetésnek nincsenek ismeretei a korábbi visszajelzési megbeszélésekről
- Ugyanazokat a túlbonyolított megoldásokat javasolják
- Nem értik a saját API-korlátaikat
- Több megbeszélést szeretnének ahelyett, hogy csak a problémát oldanák meg
Ez a minta magyarázza, hogy a PayPal csapatai miért tűnnek teljesen elszakadva a 2020-ban kapott kiterjedt visszajelzésektől – azok az emberek, akik ezt a visszajelzést kapták, már nem élnek, és az új vezetés ugyanazokat a hibákat követi el.
Évek óta figyelmen kívül hagyott hibajelentések
Nem csak hiányzó funkciókra panaszkodtunk. Aktívan jelentettük a hibákat, és megpróbáltunk segíteni a fejlesztésükben. Íme egy átfogó idővonal a dokumentált problémákról:
2016: Korai UI/UX panaszok
Már 2016-ban is nyilvánosan megkerestük a PayPal vezetőségét, köztük Dan Schulmant is, a felhasználói felülettel és a használhatósággal kapcsolatos problémákkal kapcsolatban. Ez 9 évvel ezelőtt történt, és ugyanazok a felhasználói felülettel/felhasználói élménynel kapcsolatos problémák ma is fennállnak.
2021: Üzleti e-mail hibajelentés
2021 márciusában arról számoltunk be, hogy a PayPal üzleti e-mail rendszere helytelen lemondási értesítéseket küldött. Az e-mail sablon változói helytelenül jelenítettek meg, ami zavaró üzeneteket jelenített meg az ügyfeleknek.
Mark Stuart elismerte a problémát:
Köszönöm Nick! Áttérek a BCC-re. @Prasy, a te csapatod felelős ezért az e-mailért, vagy tudod, hogy ki? A „Niftylettuce, LLC, többé nem számlázunk” szöveg miatt azt hiszem, hogy összekeveredett a címzett és az e-mail tartalma.
Eredmény: Tényleg kijavították ezt! Mark Stuart megerősítette:
Épp most hallottam az értesítési csapattól, hogy az e-mail sablont kijavították és bevezették. Köszönjük, hogy jelentetted. Köszönjük!
Ez azt mutatja, hogy MEG KÉPESEK javítani a dolgokat, amikor akarják – csak a legtöbb problémánál inkább nem teszik.
2021: Felhasználói felület fejlesztésére vonatkozó javaslatok
2021 februárjában részletes visszajelzést adtunk az irányítópult felhasználói felületéről, különösen a „PayPal legutóbbi tevékenység” részről:
Szerintem a paypal.com irányítópultját, különösen a "PayPal legutóbbi tevékenységek" részt fejleszteni kellene. Szerintem nem kellene megjeleníteni a 0 dolláros ismétlődő fizetés "Létrehozva" állapotsorait - csak egy csomó extra sort ad hozzá, és nem lehet egy pillantással áttekinteni, hogy mennyi bevételt generált a nap/az elmúlt néhány nap.
Mark Stuart továbbította a fogyasztói termékekért felelős csapatnak:
Köszönöm! Nem vagyok benne biztos, hogy melyik csapat felelős az Aktivitásért, de továbbítottam a fogyasztói termékek vezetőjének, hogy megtalálják a megfelelő csapatot. A 0,00 dolláros ismétlődő fizetés hibának tűnik. Valószínűleg ki kellene szűrni.
Eredmény: Soha nem javítva. A felhasználói felület továbbra is megjeleníti ezeket a haszontalan $0 bejegyzéseket.
2021: Sandbox környezeti hibák
2021 novemberében kritikus problémákat jelentettünk a PayPal tesztkörnyezetével kapcsolatban:
- A sandbox titkos API-kulcsai véletlenszerűen megváltoztak és letiltásra kerültek.
- Az összes sandbox tesztfiókot előzetes értesítés nélkül törölték.
- Hibaüzenetek jelentek meg a sandbox fiók adatainak megtekintésekor.
- Időszakos betöltési hibák.
Valamiért a sandbox titkos API-kulcsom megváltozott és letiltásra került. Emellett az összes régi Sandbox tesztfiókomat is törölték.
Néha betöltődik, néha nem. Ez elképesztően frusztráló.
Eredmény: Nincs válasz, nincs javítás. A fejlesztők továbbra is megbízhatósági problémákkal küzdenek a sandboxban.
2021: A jelentéskészítő rendszer teljesen összeomlott
2021 májusában arról számoltunk be, hogy a PayPal tranzakciós jelentések letöltési rendszere teljesen összeomlott:
Úgy tűnik, a letöltések jelentése most sem működik, és egész nap sem. Valószínűleg e-mail értesítést is kellene kapnom, ha nem sikerül.
Rámutattunk a munkamenet-kezelési katasztrófára is:
Továbbá, ha 5 percig inaktív vagy, miközben be vagy jelentkezve a PayPalba, kijelentkezteted magad. Tehát amikor újra frissíted a gombot a jelentés mellett, amelynek az állapotát ellenőrizni szeretnéd (miután egy örökkévalóságot vártál), kellemetlen lesz újra bejelentkezni.
Mark Stuart elismerte a munkamenet időtúllépésével kapcsolatos problémát:
Emlékszem, hogy a múltban arról számoltál be, hogy a munkameneted gyakran lejárt és megzavarta a fejlesztési folyamatot, miközben az IDE és a developer.paypal.com vagy a kereskedői irányítópult között váltogattál, majd visszatértél és újra kijelentkeztettek.
Eredmény: A munkamenetek időtúllépései továbbra is 60 másodpercesek. A jelentéskészítő rendszer továbbra is rendszeresen leáll.
2022: Hiányzik az alap API-funkció (ismét)
2022 januárjában ismét eszkaláltuk az előfizetési listával kapcsolatos problémát, ezúttal még részletesebben ismertetve a dokumentációjuk hibás voltát:
Nincs olyan GET függvény, amely felsorolja az összes előfizetést (korábban számlázási szerződéseknek nevezték)
Felfedeztük, hogy a hivatalos dokumentációjuk teljesen pontatlan:
Az API dokumentáció is teljesen pontatlan. Azt gondoltuk, hogy megkerülő megoldásként letölthetünk egy fixen kódolt listát az előfizetés-azonosítókról. De még ez sem működik!
A hivatalos dokumentáció szerint... Azt mondják, ezt megteheted... Itt a lényeg - sehol sincs kipipálható "Előfizetés-azonosító" mező.
Christina Monti a PayPaltól így válaszolt:
Elnézést kérünk a hibás lépések okozta kellemetlenségekért, a héten kijavítjuk.
Sri Shivananda (CTO) megköszönte nekünk:
Köszönjük a folyamatos segítségedet, amivel jobbá teszel minket. Nagyra értékeljük.
Eredmény: A dokumentációt soha nem javították. Az előfizetési lista végpontját soha nem hozták létre.
A fejlesztői élmény rémálma
A PayPal API-jaival dolgozni olyan, mintha 10 évet visszamennénk az időben. Íme a dokumentált technikai problémák:
Hibás felhasználói felület
A PayPal fejlesztői irányítópultja egy katasztrófa. Íme, mivel foglalkozunk nap mint nap:
SDK-problémák
- Nem tudja egyszerre fizetni és előfizetni az egyszeri fizetéseket és az előfizetéseket is bonyolult kerülő megoldások nélkül, amelyek magukban foglalják a gombok cseréjét és újrarenderelését az SDK szkriptcímkékkel történő újratöltése során.
- A JavaScript SDK megsérti az alapvető konvenciókat (kisbetűs osztálynevek, nincs példányellenőrzés).
- A hibaüzenetek nem jelzik, hogy mely mezők hiányoznak.
- Inkonzisztens adattípusok (számok helyett karakterlánc-összegeket igényel).
Tartalombiztonsági irányelvek megsértése
Az SDK-juk unsafe-inline és unsafe-eval funkciókat igényel a CSP-ben, ami arra kényszerít, hogy veszélyeztesse webhelye biztonságát.
Dokumentációs káosz
Maga Mark Stuart is elismerte:
Egyetértek, hogy abszurd mennyiségű régi és új API van. Nagyon nehéz megtalálni, amit keresni kellene (még nekünk is, akik itt dolgozunk).
Biztonsági réseket
A PayPal 2FA implementációja fordított. Még ha a TOTP alkalmazások engedélyezve is vannak, akkor SMS-ellenőrzést kényszerítenek ki, ami sebezhetővé teszi a fiókokat a SIM-kártya-csere támadásokkal szemben. Ha a TOTP engedélyezve van, akkor kizárólag azt kellene használnia. A tartalék megoldásnak e-mailnek kell lennie, nem SMS-nek.
Munkamenet-kezelési katasztrófa
A fejlesztői irányítópultjuk 60 másodperc tétlenség után kijelentkeztet. Ha bármi hasznos dolgot próbálsz csinálni, folyamatosan ezt a folyamatot kell végrehajtanod: bejelentkezés → captcha → 2FA → kijelentkezés → ismétlés. VPN-t használsz? Sok sikert!
2025. július: Az utolsó csepp a pohárban
11 évnyi ugyanazon problémák után a töréspont egy rutinszerű fiókmigráció során jött el. Új PayPal-számlára kellett átállnunk, hogy az megegyezzen a "Forward Email LLC" cégnevünkkel a tisztább könyvelés érdekében.
Aminek egyszerűnek kellett volna lennie, teljes katasztrófává vált:
- A kezdeti tesztek azt mutatták, hogy minden megfelelően működött.
- Órákkal később a PayPal hirtelen, előzetes értesítés nélkül blokkolta az összes előfizetési fizetést.
- Az ügyfelek nem tudtak fizetni, ami zavart és támogatási terhet okozott.
- A PayPal támogatása ellentmondásos válaszokat adott, azt állítva, hogy a fiókok ellenőrizve vannak.
- Kénytelenek voltunk teljesen leállítani a PayPal-fizetéseket.
Miért nem tudjuk csak úgy elvetni a PayPalt
Mindezen problémák ellenére sem hagyhatjuk el teljesen a PayPalt, mivel egyes ügyfelek csak a PayPalt választhatják fizetési lehetőségként. Ahogy az egyik ügyfél mondta a állapotoldal oldalon:
A PayPal az egyetlen fizetési lehetőségem
Megragadtunk egy hibás platform támogatásával, mert a PayPal fizetési monopóliumot hozott létre bizonyos felhasználók számára.
Közösségi kerülő megoldás
Mivel a PayPal nem biztosít alapvető előfizetési listázási funkciókat, a fejlesztői közösség megkerülő megoldásokat dolgozott ki. Létrehoztunk egy szkriptet, amely segít a PayPal-előfizetések kezelésében: set-active-pypl-subscription-ids.js
Ez a szkript egy közösségi lényeg-ra hivatkozik, ahol a fejlesztők megosztják a megoldásaikat. A felhasználók valójában megköszönve nekünk-ként szerepelnek, mert olyan dolgokat kínálnak, amiket a PayPalnak évekkel ezelőtt kellett volna létrehoznia.
PayPal-sablonok blokkolása adathalászat miatt
A problémák túlmutatnak az API-kon. A PayPal e-mail sablonjai annyira rosszul vannak megtervezve, hogy speciális szűrést kellett bevezetnünk az e-mail szolgáltatásunkban, mivel ezek megkülönböztethetetlenek az adathalász kísérletektől.
Az igazi probléma: A PayPal sablonjai átverésnek tűnnek
Rendszeresen kapunk jelentéseket PayPal-os e-mailekről, amelyek pontosan adathalász kísérleteknek tűnnek. Íme egy valós példa a visszaélési jelentéseink közül:
Tárgy: IDEIGLENES_HELYTARTÓ_0
Ez az e-mail továbbításra került a abuse@microsoft.com címre, mert adathalász kísérletnek tűnt. Mi a probléma? Valójában a PayPal sandbox környezetéből érkezett, de a sablonjuk annyira gyenge, hogy elindítja az adathalászat-észlelő rendszereket.
A mi implementációnk
A PayPal-specifikus szűrésünket a e-mail szűrőkód paraméterben láthatja:
// check for paypal scam (very strict until PayPal resolves phishing on their end)
// (seems to only come from "outlook.com" and "paypal.com" hosts)
//
// X-Email-Type-Id = RT000238
// PPC001017
// RT000542 = gift message hack
// RT002947 = paypal invoice spam
// <https://www.bleepingcomputer.com/news/security/beware-paypal-new-address-fraud/>
//
if (
session.originalFromAddressRootDomain === 'paypal.com' &&
headers.hasHeader('x-email-type-id') &&
['PPC001017', 'RT000238', 'RT000542', 'RT002947'].includes(
headers.getFirst('x-email-type-id')
)
) {
const err = new SMTPError(
'Due to ongoing PayPal invoice spam, you must manually send an invoice link'
);
err.isCodeBug = true; // alert admins for inspection
throw err;
}
Miért kellett blokkolnunk a PayPalt
Ezt azért vezettük be, mert a PayPal a visszaélésekkel foglalkozó csapatoknak küldött többszöri jelentéseink ellenére sem volt hajlandó kijavítani a hatalmas spam/adathalászat/csalási problémákat. Az általunk blokkolt konkrét e-mail típusok a következők:
- RT000238 - Gyanús számlákkal kapcsolatos értesítések
- PPC001017 - Problémás fizetési visszaigazolások
- RT000542 - Ajándéküzenetek feltörési kísérletei
A probléma mértéke
A spamszűrő naplóink azt mutatják, hogy naponta hatalmas mennyiségű PayPal-számlára érkező spam-et dolgozunk fel. A blokkolt témák például a következők:
- „Számla a PayPal számlázási csapatától:- Ez a tétel automatikusan terhelésre kerül a számlájáról. Kérjük, azonnal vegye fel velünk a kapcsolatot a következő telefonszámon: [TELEFONSZÁM]”
- „Számla a következő cégtől: [CÉGNÉV] ([RENDELÉSI AZONOSÍTÓ])”
- Több változat különböző telefonszámokkal és hamis rendelési azonosítókkal
Ezek az e-mailek gyakran outlook.com hosztokról érkeznek, de úgy tűnik, hogy a PayPal legitim rendszereiből származnak, ami különösen veszélyessé teszi őket. Az e-mailek SPF, DKIM és DMARC hitelesítésen esnek át, mivel a PayPal tényleges infrastruktúráján keresztül küldik őket.
Technikai naplóink szerint ezek a spam e-mailek érvényes PayPal-fejléceket tartalmaznak:
X-Email-Type-Id: RT000238(ugyanaz az azonosító, amit blokkolunk)From: "service@paypal.com" <service@paypal.com>- Érvényes DKIM aláírások a
paypal.com-től - Megfelelő SPF-rekordok, amelyek a PayPal levelezőszervereit mutatják
Ez lehetetlen helyzetet teremt: a legitim PayPal e-mailek és a spam technikai jellemzői megegyeznek.
Az irónia
A PayPal, egy olyan vállalat, amelynek vezető szerepet kellene vállalnia a pénzügyi csalások elleni küzdelemben, olyan rosszul megtervezett e-mail sablonokkal rendelkezik, hogy adathalászat elleni rendszereket aktiválnak. Kénytelenek vagyunk blokkolni a legitim PayPal e-maileket, mivel azok megkülönböztethetetlenek a csalásoktól.
Ez a Óvakodj a PayPal új címével kapcsolatos csalásoktól biztonsági kutatásban dokumentálva van, amely bemutatja, hogyan használják ki a PayPal saját rendszereit csalásokra.
Valós hatás: Új PayPal-csalások
A probléma túlmutat a rossz sablontervezésen. A PayPal számlázási rendszerét annyira könnyű kihasználni, hogy a csalók rendszeresen visszaélnek vele, hogy legitimnek tűnő, csalárd számlákat küldjenek. Gavin Anderegg biztonsági kutató dokumentálta a Egy újszerű PayPal-átverés esetet, ahol a csalók valódi PayPal-számlákat küldenek, amelyek minden hitelesítési ellenőrzésen átmennek:
„A forrást megvizsgálva úgy tűnt, hogy az e-mail valójában a PayPal-tól érkezett (az SPF, a DKIM és a DMARC is megfelelt). A gomb egy legitim PayPal URL-re is mutatott... Egy pillanatba telt, mire rájöttem, hogy ez egy legitim e-mail. Épp most kaptam egy véletlenszerű „számlát” egy csalótól.”
A kutató megjegyezte:
„Úgy tűnik, ez egy olyan kényelmi funkció, amelynek a lezárását a PayPalnak meg kellene fontolnia. Azonnal azt hittem, hogy ez valami átverés, és csak a technikai részletek érdekeltek. Túl könnyűnek tűnik megvalósítani, és attól tartok, hogy mások bedőlhetnek neki.”
Ez tökéletesen illusztrálja a problémát: a PayPal saját legitim rendszerei annyira rosszul vannak megtervezve, hogy lehetővé teszik a csalást, miközben a legitim kommunikációt gyanúsnak tüntetik fel.
Ráadásul ez a Yahoo-val való kézbesítésünket is befolyásolta, ami ügyfélpanaszokhoz, valamint órákig tartó aprólékos teszteléshez és mintaellenőrzéshez vezetett.
A PayPal fordított KYC folyamata
A PayPal platformjának egyik legfrusztrálóbb aspektusa a megfelelőségi és az „Ismerd meg az ügyfeledet” (KYC) eljárások fordított megközelítése. Minden más fizetési processzorral ellentétben a PayPal lehetővé teszi a fejlesztők számára, hogy integrálják API-jaikat, és elkezdjék a fizetések beszedését éles környezetben, mielőtt elvégeznék a megfelelő ellenőrzést.
Hogyan kellene működnie
Minden legitim fizetésfeldolgozó a következő logikai sorrendet követi:
- Először végezze el a KYC-ellenőrzést
- Jóváhagyja a kereskedői fiókot
- Adjon meg termelési API-hozzáférést
- Engedélyezze a fizetések beszedését
Ez mind a fizetésfeldolgozót, mind a kereskedőt védi azáltal, hogy biztosítja a megfelelést, mielőtt bármilyen pénz gazdát cserélne.
Hogyan működik valójában a PayPal
A PayPal folyamata teljesen fordított:
- Azonnal biztosítson API-hozzáférést az éles környezetben
- Engedélyezze a fizetések beszedését órákra vagy napokra
- Hirtelen, értesítés nélküli blokkolja a fizetéseket
- Kövesse a KYC dokumentációt, miután az ügyfeleket már érinti a probléma
- Ne értesítse a kereskedőt
- Hagyja, hogy az ügyfelek felfedezzék és jelentsék a problémát
A valós hatás
Ez a fordított folyamat katasztrófákat okoz a vállalkozások számára:
- A csúcsidőszakokban a vásárlók nem tudják befejezni a vásárlásaikat
- Nincs előzetes figyelmeztetés arról, hogy ellenőrzésre van szükség
- Nincs e-mail értesítés, ha a fizetések blokkolva vannak
- A kereskedők az összezavarodott vásárlóktól értesülnek a problémákról
- Bevételkiesés kritikus üzleti időszakokban
- A vásárlói bizalom romlása, amikor a fizetések rejtélyes módon meghiúsulnak
A 2025. júliusi fiókmigrációs katasztrófa
Pontosan ez a forgatókönyv játszódott le a 2025 júliusi rutinszerű fiókmigrációnk során. A PayPal kezdetben engedélyezte a fizetéseket, majd hirtelen, mindenféle értesítés nélkül blokkolta azokat. Csak akkor vettük észre a problémát, amikor az ügyfelek elkezdték jelenteni, hogy nem tudnak fizetni.
Amikor felvettük a kapcsolatot az ügyfélszolgálattal, ellentmondásos válaszokat kaptunk a szükséges dokumentációkról, a megoldásra vonatkozó egyértelmű határidő nélkül. Emiatt kénytelenek voltunk teljesen leállítani a PayPal-fizetéseket, összezavarva azokat az ügyfeleket, akiknek nem volt más fizetési lehetőségük.
Miért fontos ez?
A PayPal megfelelési megközelítése alapvető félreértést mutat a vállalkozások működésével kapcsolatban. A megfelelő KYC-nek a termelési integráció előtt kell történnie, nem pedig azután, hogy az ügyfelek már megpróbálnak fizetni. A proaktív kommunikáció hiánya a problémák felmerülésekor a PayPal kereskedői igényektől való eltávolodását mutatja.
Ez a fordított folyamat a PayPal tágabb szervezeti problémáinak tünete: a belső folyamataikat helyezik előtérbe a kereskedői és ügyfélélménnyel szemben, ami olyan működési katasztrófákhoz vezet, amelyek elriasztják a vállalkozásokat a platformjuktól.
Hogyan csinálja ezt helyesen minden más fizetési szolgáltató
Az előfizetési lista funkció, amelyet a PayPal nem hajlandó bevezetni, több mint egy évtizede szabványos az iparágban. Így kezelik ezt az alapvető követelményt más fizetési szolgáltatók:
Csík
A Stripe az API indulása óta rendelkezik előfizetési listázással. A dokumentációjuk világosan bemutatja, hogyan lehet lekérni egy ügyfél- vagy kereskedői fiók összes előfizetését. Ez alapvető CRUD funkciónak számít.
Evező
A Paddle átfogó előfizetés-kezelési API-kat kínál, beleértve a listázást, a szűrést és a lapozást. Megértik, hogy a kereskedőknek látniuk kell a visszatérő bevételi forrásaikat.
Coinbase Commerce
Még a kriptovaluta-fizetési szolgáltatók, mint például a Coinbase Commerce, is jobb előfizetés-kezelést biztosítanak, mint a PayPal.
Négyzet
A Square API-ja alapvető funkcióként tartalmazza az előfizetési listázást, nem pedig utólagos gondolatként.
Az iparági szabvány
Minden modern fizetési processzor a következőket kínálja:
- Összes előfizetés listázása
- Szűrés állapot, dátum, ügyfél szerint
- Oldalszámozás nagy adathalmazokhoz
- Webhook értesítések az előfizetés-változásokról
- Átfogó dokumentáció működő példákkal
Mit kínálnak más adatfeldolgozók a PayPalhoz képest
Stripe – Összes előfizetés listázása:
GET https://api.stripe.com/v1/subscriptions
Authorization: Bearer sk_test_...
Response:
{
"object": "list",
"data": [
{
"id": "sub_1MowQVLkdIwHu7ixeRlqHVzs",
"object": "subscription",
"status": "active",
"customer": "cus_Na6dX7aXxi11N4",
"current_period_start": 1679609767,
"current_period_end": 1682288167
}
],
"has_more": false
}
Stripe - Szűrés ügyfél szerint:
GET https://api.stripe.com/v1/subscriptions?customer=cus_Na6dX7aXxi11N4
Csík - Szűrés állapot szerint:
GET https://api.stripe.com/v1/subscriptions?status=active
PayPal – Amit valójában kapsz:
GET https://api.paypal.com/v1/billing/subscriptions/{id}
Authorization: Bearer access_token
# You can ONLY get ONE subscription if you already know the ID
# There is NO endpoint to list all subscriptions
# There is NO way to search or filter
# You must track all subscription IDs yourself
A PayPal elérhető végpontjai:
POST /v1/billing/subscriptions- Előfizetés létrehozásaGET /v1/billing/subscriptions/{id}- EGY előfizetés beszerzése (ha ismeri az azonosítót)PATCH /v1/billing/subscriptions/{id}- Előfizetés frissítésePOST /v1/billing/subscriptions/{id}/cancel- Előfizetés lemondásaPOST /v1/billing/subscriptions/{id}/suspend- Előfizetés felfüggesztése
Ami hiányzik a PayPalból:
- ❌ Nincs
GET /v1/billing/subscriptions(összes listázása) - ❌ Nincs keresési funkció
- ❌ Nincs szűrés állapot, ügyfél, dátum szerint
- ❌ Nincs oldalszámozás támogatás
A PayPal az egyetlen jelentős fizetési szolgáltató, amely arra kényszeríti a fejlesztőket, hogy manuálisan kövessék nyomon az előfizetési azonosítókat a saját adatbázisaikban.
A PayPal szisztematikus eltussolása: 6 millió hang elhallgattatása
A PayPal kritikák kezeléséhez való hozzáállását tökéletesen megtestesítő lépésként nemrégiben offline állapotba hozták teljes közösségi fórumukat, gyakorlatilag elhallgattatva több mint 6 millió tagot, és törölve több százezer, a hibáikat dokumentáló bejegyzést.
A nagy törlés
Az eredeti PayPal közösség a paypal-community.com címen 6 003 558 tagot számlált, és több százezer bejegyzést, hibajelentést, panaszt és beszélgetést tartalmazott a PayPal API-hibáiról. Ez több mint egy évtizednyi dokumentált bizonyítékot jelentett a PayPal szisztematikus problémáira.
- június 30-án a PayPal csendben leállította a teljes fórumot. Az összes
paypal-community.comlink most 404-es hibát ad vissza. Ez nem migráció vagy frissítés volt.
Harmadik féltől származó mentés
Szerencsére egy harmadik féltől származó szolgáltatás a ppl.lithium.com címen megőrizte a tartalom egy részét, lehetővé téve számunkra, hogy hozzáférjünk azokhoz a beszélgetésekhez, amelyeket a PayPal megpróbált elrejteni. Ez a harmadik fél általi megőrzés azonban nem teljes, és bármikor eltűnhet.
A bizonyítékok elrejtésének ez a mintája nem új a PayPal számára. Dokumentált múlttal rendelkeznek a következőkről:
- Kritikus hibajelentések eltávolítása a nyilvánosság elől
- Fejlesztői eszközök értesítés nélküli megszüntetése
- API-k megfelelő dokumentáció nélküli módosítása
- A hibáikról szóló közösségi viták elhallgattatása
A fórumtörlés a legagyalázatosabb kísérlet arra, hogy a nyilvánosság elől elrejtsék a rendszerszintű hibáikat.
A 11 éve tartó capture hiba katasztrófája: 1899 dollár, és ez a szám még növekszik
Miközben a PayPal a visszajelzési megbeszélések szervezésével és ígéretek tételével volt elfoglalva, az alapvető fizetésfeldolgozó rendszerük több mint 11 éve alapvetően összeomlott. A bizonyítékok lesújtóak.
Továbbított e-mail 1899 dolláros vesztesége
Éles rendszereinkben 108 PayPal-fizetést fedeztünk fel, összesen 1899 USD értékben, amelyek a PayPal rögzítési hibái miatt elvesztek. Ezek a fizetések következetes mintát mutatnak:
CHECKOUT.ORDER.APPROVEDwebhookok érkeztek- A PayPal capture API-ja 404 hibát adott vissza
- A megrendelések elérhetetlenné váltak a PayPal API-ján keresztül
Lehetetlen megállapítani, hogy az ügyfeleknek felszámították-e a díjat, mivel a PayPal 14 nap elteltével teljesen elrejti a hibakeresési naplókat, és törli az irányítópultról a nem rögzített rendelési azonosítókhoz tartozó összes adatot.
Ez csak egyetlen vállalkozást képvisel. A több ezer kereskedő összesített vesztesége több mint 11 év alatt valószínűleg több millió dollárt tesz ki.
Újra hangsúlyozzuk: több ezer kereskedő összesített veszteségei több mint 11 év alatt valószínűleg több millió dollárt tesznek ki.
Az egyetlen ok, amiért ezt felfedeztük, az az, hogy hihetetlenül aprólékosak és adatvezéreltek vagyunk.
A 2013-as eredeti jelentés: Több mint 11 évnyi hanyagság
A probléma legkorábbi dokumentált jelentése a Stack Overflow 2013 novemberében (archivált) címen található:
„Folyamatosan 404-es hibát kapunk Rest API-val rögzítés közben”
A 2013-ban jelentett hiba azonos azzal, amit a Forward Email 2024-ben tapasztalt:
{
"name": "INVALID_RESOURCE_ID",
"message": "The requested resource ID was not found",
"information_link": "https://developer.paypal.com/webapps/developer/docs/api/#INVALID_RESOURCE_ID",
"debug_id": "e56bae98dcc26"
}
A közösség reakciója 2013-ban sokatmondó volt:
„Jelenleg jelentettünk egy problémát a REST API-val. A PayPal dolgozik a megoldásán.”
Több mint 11 évvel később még mindig „dolgoznak rajta”.
A 2016-os beismerés: A PayPal feltörte a saját SDK-ját
2016-ban a PayPal saját GitHub adattára dokumentálta, hogy a hatalmas befogási kudarcok hatással volt a hivatalos PHP SDK-jukra. A mérték megdöbbentő volt:
„2016. szeptember 20. óta az összes PayPal-rögzítési kísérlet „INVALID_RESOURCE_ID - A kért erőforrás-azonosító nem található” hibával sikertelen. Szeptember 19. és szeptember 20. között semmi sem változott az API-integrációban. September 20. óta a rögzítési kísérletek 100%-a ezt a hibát adta vissza.”
Egy kereskedő jelentette:
„Az elmúlt 24 órában több mint 1400 sikertelen rögzítési kísérletem volt, mindegyik INVALID_RESOURCE_ID hibaválaszjel.”
A PayPal kezdeti válasza az volt, hogy a kereskedőt hibáztatta, és technikai támogatáshoz irányította. Csak hatalmas nyomásgyakorlás után ismerték el a hibájukat:
„Friss értesítést kaptam a termékfejlesztőinktől. Észrevették a küldött fejlécekben, hogy a PayPal-Request-ID 42 karakterből áll, de úgy tűnik, hogy nemrégiben történt egy változás, amely ezt az azonosítót mindössze 38 karakterre korlátozza.”
Ez a beismerés a PayPal szisztematikus hanyagságát fedi fel:
- Dokumentálatlan, törésmutató változtatásokat hajtottak végre
- A saját hivatalos SDK-jukat tették tönkre
- Először a kereskedőket hibáztatták
- Csak nyomás alatt ismerték el a hibájukat
A probléma „megoldása” után is a kereskedők a következőkről számoltak be:
„Frissítettem az SDK-t 1.7.4-es verzióra, és a probléma továbbra is fennáll.”
A 2024-es eszkaláció: Még mindig hibás
A megőrzött PayPal-közösség legfrissebb jelentései szerint a probléma valójában rosszabbodott. A 2024. szeptemberi megbeszélés (archivált) pontosan ugyanazokat a problémákat dokumentálja:
„A probléma csak körülbelül 2 hete kezdett jelentkezni, és nem érinti az összes rendelést. A sokkal gyakoribbnak tűnik a 404-es hiba a rögzítéskor.”
A kereskedő ugyanazt a mintát írja le, mint amit az e-mail továbbításakor tapasztalt:
„A megrendelés rögzítésére tett kísérlet után a PayPal 404-es hibát ad vissza. A megrendelés részleteinek lekérésekor: {'id': 'ID', 'intent': 'CAPTURE', 'status': 'COMPLETED', ..., 'final_capture': true, ...} Ez a mi oldalunkon a sikeres rögzítésnek semmilyen nyomát nem mutatja.”
A webhook megbízhatósági katasztrófája
Egy másik megőrzött közösségi beszélgetés felfedi, hogy a PayPal webhook rendszere alapvetően megbízhatatlan:
„Elméletileg két eseménynek kellene lennie (CHECKOUT.ORDER.APPROVED és PAYMENT.CAPTURE.COMPLETED) a Webhook eseménytől. Valójában**ez a két esemény ritkán érkezik be azonnal, a PAYMENT.CAPTURE.COMPLETED a legtöbb esetben nem, vagy csak néhány órán belül érkezne meg.”
Előfizetési fizetések esetén:
„A 'PAYMENT.SALE.COMPLETED' fizetési művelet néha csak néhány óra elteltével érkezett meg.””
A kereskedő kérdései rávilágítanak a PayPal megbízhatósági problémáinak mélységére:
- „Miért történik ez?” - A PayPal webhook rendszere alapvetően hibás.
- „Ha a rendelés állapota „BEFEJEZVE”, akkor feltételezhetem, hogy megkaptam a pénzt?” - A kereskedők nem bízhatnak a PayPal API-válaszaiban.
- „Miért nem talál naplókat az „Eseménynaplók->Webhook események” menüpont?” - Még a PayPal saját naplózórendszere sem működik.
A szisztematikus hanyagság mintázata
A bizonyítékok több mint 11 évet ölelnek fel, és egyértelmű mintázatot mutatnak:
- 2013: „A PayPal dolgozik rajta”
- 2016: A PayPal elismeri a hibás változást, és hibás javítást nyújt
- 2024: Ugyanazok a hibák továbbra is előfordulnak, amelyek a Forward Email és számtalan más szolgáltatást érintenek
Ez nem hiba – ez szisztematikus hanyagság. A PayPal több mint egy évtizede tud ezekről a kritikus fizetésfeldolgozási hibákról, és következetesen:
- A kereskedőket hibáztatták a PayPal hibáiért
- Nem dokumentált, hibás változtatásokat eszközöltek
- Nem megfelelő, de nem működő javításokat biztosítottak
- Figyelmen kívül hagyták a vállalkozásokra gyakorolt pénzügyi hatásokat
- Bizonyítékokat rejtettek el a közösségi fórumok eltávolításával
A nem dokumentált követelmény
A PayPal hivatalos dokumentációjában sehol sem említik, hogy a kereskedőknek újrapróbálkozási logikát kellene alkalmazniuk a rögzítési műveletekhez. A dokumentációjuk szerint a kereskedőknek „a jóváhagyás után azonnal rögzíteniük kell”, de nem említik, hogy az API-juk véletlenszerűen 404-es hibákat ad vissza, amelyek összetett újrapróbálkozási mechanizmusokat igényelnek.
Ez minden kereskedőt arra kényszerít, hogy:
- Exponenciális visszatartási újrapróbálkozási logika megvalósítása
- Inkonzisztens webhook-kézbesítés kezelése
- Komplex állapotkezelő rendszerek létrehozása
- Sikertelen rögzítések manuális figyelése
Minden más fizetésfeldolgozó megbízható, elsőre működő rögzítési API-kat kínál.
A PayPal megtévesztési gyakorlatának szélesebb körű elterjedtsége
A capture bug katasztrófa csak egy példa a PayPal szisztematikus megközelítésére az ügyfelek megtévesztésére és a hibáik eltitkolására.
A New York-i Pénzügyi Szolgáltatások Minisztériumának intézkedése
2025 januárjában a New York-i Pénzügyi Szolgáltatások Minisztériuma végrehajtási intézkedés a PayPal ellen számú figyelmeztetést adott ki megtévesztő gyakorlatok miatt, ami azt mutatja, hogy a PayPal megtévesztő gyakorlata messze túlmutat az API-jain.
Ez a szabályozási intézkedés azt mutatja, hogy a PayPal hajlandó megtévesztő gyakorlatokat folytatni a teljes üzleti tevékenységében, nem csak a fejlesztői eszközeiben.
A mézper: Partnerlinkek átírása
A PayPal Honey felvásárlása perek, amelyek azt állítják, hogy Honey átírja affiliate linkeket címet eredményezett, jutalékokat lopva el tartalomkészítőktől és influenszerektől. Ez a szisztematikus megtévesztés egy másik formáját képviseli, ahol a PayPal olyan bevételek átirányításával profitál, amelyeknek másoknak kellene menniük.
A minta egyértelmű:
- API hibák: Hibás funkciók elrejtése, kereskedők hibáztatása
- Közösség elhallgattatása: A problémák bizonyítékainak eltávolítása
- Szabályozási jogsértések: Megtévesztő gyakorlatok folytatása
- Partnerlopás: Jutalékok ellopása technikai manipulációval
A PayPal hanyagságának ára
A Forward Email 1899 dolláros vesztesége csak a jéghegy csúcsa. Vegyük figyelembe a tágabb hatást is:
- Egyéni kereskedők: Több ezer dolláros veszteség fejenként
- Vállalati ügyfelek: Potenciálisan több millió dolláros bevételkiesés
- Fejlesztői idő: Számtalan óra a PayPal hibás API-jainak megkerülő megoldásainak kidolgozásával
- Ügyfélbizalom: Vállalkozások veszítenek ügyfeleket a PayPal fizetési hibái miatt
Ha egyetlen kis e-mail szolgáltatás közel 2000 dolláros veszteséget szenvedett el, és ez a probléma több mint 11 éve fennáll, és több ezer kereskedőt érint, akkor a teljes pénzügyi kár valószínűleg több százmillió dollár.
A dokumentációs hazugság
A PayPal hivatalos dokumentációja következetesen nem említi a kereskedők által tapasztalható kritikus korlátozásokat és hibákat. Például:
- Rögzítési API: Nincs említés arról, hogy a 404-es hibák gyakoriak és újrapróbálkozási logikát igényelnek.
- Webhook megbízhatósága: Nincs említés arról, hogy a webhookok gyakran órákkal késnek.
- Előfizetési listázás: A dokumentáció szerint a listázás akkor is lehetséges, ha nincs végpont.
- Munkamenet-időtúllépések: Nincs említés az agresszív 60 másodperces időtúllépésekről.
A kritikus információk szisztematikus elhallgatása arra kényszeríti a kereskedőket, hogy a termelési rendszerekben próbálgatással és hibákkal fedezzék fel a PayPal korlátait, ami gyakran pénzügyi veszteségekhez vezet.
Mit jelent ez a fejlesztők számára?
A PayPal szisztematikus kudarca az alapvető fejlesztői igények kielégítésében, miközben kiterjedt visszajelzéseket gyűjt, egy alapvető szervezeti problémára utal. A visszajelzések gyűjtését a tényleges problémák megoldásának helyettesítőjeként kezelik.
A minta egyértelmű:
- A fejlesztők jelentik a problémákat.
- A PayPal visszajelzési megbeszéléseket szervez a vezetőkkel.
- Kiterjedt visszajelzéseket adnak.
- A csapatok elismerik a hiányosságokat, és megígérik, hogy „nyomon követik és kezelik azokat”.
- Semmi sem kerül megvalósításra.
- A vezetők jobb cégekhez távoznak.
- Az új csapatok ugyanazt a visszajelzést kérik.
- A ciklus ismétlődik.
Eközben a fejlesztők kénytelenek megkerülő megoldásokat találni, veszélyeztetni a biztonságot és hibás felhasználói felületekkel foglalkozni, csak hogy elfogadhassák a fizetéseket.
Ha fizetési rendszert építesz, tanulj a tapasztalatainkból: építsd fel a trifecta megközelítés-dat több processzorral, de ne várd el a PayPaltól, hogy biztosítsa a szükséges alapvető funkciókat. Tervezd meg a kerülő megoldások kidolgozását az első naptól kezdve.
Ez a bejegyzés a Forward Email PayPal API-jaival szerzett 11 éves tapasztalatunkat dokumentálja. Minden kódpélda és link a tényleges éles rendszereinkből származik. A problémák ellenére továbbra is támogatjuk a PayPal-fizetéseket, mivel egyes ügyfeleknek nincs más lehetőségük.
