01Minden fizetési mód egy oldalon
A hosted checkout egymás mellett mutatja a kártyát, az Apple Payt, a Google Payt és az USDC-t. Balra a 9F21-0716 rendelés — három tétel, €0.50 feldolgozási díj, €49.00 fizetendő —, jobbra a fizetési mód kiválasztása. Az ügyfél választ, az oldal alkalmazkodik, a kereskedő pedig egyszer integrált.
- Kártya-, USDC- és wallet gombok ugyanazon a képernyőn
- A teljes rendelés — tételek, díjak, végösszeg — a fizetési űrlap mellett
- Egyetlen „Fizetés €49.00” művelet, módtól függetlenül
02Mobilon is ugyanarról az URL-ről
Ugyanaz a checkout URL telefonos elrendezésbe rendeződik át: a rendelés összesítő sávba csukódik, a fizetésimód-gombok a helyükön maradnak, a kártyaűrlap megtartja a címkéit. Ami asztali gépen működik, mobilon is működik — és ha a fizetésnek a saját alkalmazásodban kell megtörténnie böngésző helyett, az iOS és Android SDK-k natívan jelenítik meg ugyanazt a checkoutot ugyanahhoz a rendeléshez.
03Magukért beszélő nyugták
Az USDC-vel fizetés olyan nyugtával zárul, amelyet a kereskedő könyvelője is el tud olvasni. Mód: 52.95 USDC Base-en →︎ EUR elszámolás, a nyugtán feltüntetett árfolyamon, 1 EUR = 1.0807 USDC. Hivatkozás: 9F21-0716, e-mailben elküldve az ügyfélnek és azonnal letölthető. Az ügyfél kriptóval fizetett; a könyvekben €49.00 szerepel.
04Linkek back office-szal, nem csak linkek
A fizetési linkek valódi munkafelületet kapnak: 8 link az Arc Studio SRL-nek kifizetett, aktív és lejárt állapotban, soronként az összeggel, a fizetések számával és az állapottal. A fenti kártyák vezetik az állást — 4 aktív link, €2,304.50 beszedve ebben a hónapban 18 linkes fizetésből, €49.00 kifizetve ma. Létrehozás, keresés, export, kész.
- Minden link az URL-jével, összegével és állapotával
- A havi beszedés és a mai kifizetések legfelül
- Linket létrehozni ugyanabban a nézetben lehet, ahol követed őket
05Visszatérítés a rendeléshez
A visszatérítés a rendelésre mutat, nem a fizetési módra. A panel a 9F21-0716 rendelésen nyílik meg, az összeg előre kitöltve a teljes €49.00-val, kötelező indoklással és egy opcionális megjegyzéssel, amely bekerül az exportokba és az ügyfél nyugtájára. A pénz automatikusan az eredeti fizetési úton megy vissza — a kártyás visszatérítés a kártyára, az USDC-s rendelések az EUR elszámolásuk szerint —, jellemzően 1–3 munkanap alatt.
- Teljes vagy részleges — az eredeti terhelésig bármekkora összeg
- Indoklás kötelező, a megjegyzés a nyugtára kerül
- Az eredeti útvonal automatikus visszafordítása, mindkét rail esetén
06A checkoutod, látványosan a tiéd
A márkajelzés egy beállítási oldal, nem szolgáltatási projekt: tölts fel logót, állítsd be a kiemelő-, szöveg- és felületszíneket, válassz betűtípust és sarokstílust. Az élő előnézet mentés előtt a valódi checkoutodat jeleníti meg — asztali vagy mobil nézetben —, a kiemelőszín pedig a fizetés gomb fókuszát, az állapotjelzőket és az aktív tabot adja. Futtasd a sandboxhoz kiadott checkout hoston, vagy a saját domainen.
07Fizetési módok, amiket kapcsolsz, nem építesz
A fizetési módok kapcsolók, mögöttük szolgáltatókkal: kártyák 3-D Secure-ral, Apple Pay és Google Pay wallet gombként, USDC Ethereumon, Base-en és Solanán, SEPA banki átutalás vIBAN hivatkozással. Mellettük az elszámolási panel egyszerűen kimondja a lényeget: az ügyfelek megerősítés előtt látják az átváltást; te mindig EUR-ban számolsz el.
- Módonkénti kapcsolók, a soron a szolgáltató nevével
- USDC elszámolás: automatikus átváltás, napi kifizetés 23:00-kor
- Kártyaroutolás látható 3-D Secure szabályzattal
08Drop-in integráció
Hozz létre egy rendelést, irányítsd át a hosted oldalra, fogadd az eredményt. A Gateway viszi a fizetési felületet, a módok logikáját és a nyugtákat. Nincs checkout frontend, amit a csapatodnak építenie, javítania vagy a módok változásával naprakészen tartania kellene.
09A rendelés az egység
Minden a rendeléshez kapcsolódik, nem a fizetési módhoz. A 9F21-0716 rendelés tételei — €38.50 arculattervezési sprint, €6.00 betűtípus-licenc, €4.00 sürgős szállítás —, a €0.50 feldolgozási díj és egyetlen végösszeg. Bárhogy is fizetnek, erre a hivatkozásra kérdezel le, egyeztetsz és térítesz vissza.
10Konfiguráció, ami nem lepi meg a munkamenetet
A fizetésimód- és arculatváltozások az új checkout munkamenetekre érvényesek — ezt maga a mentés képernyője is kimondja. A fizetés közben lévő ügyfél alatt sosem változik meg az oldal.
11Kártya, rendesen
A kártyás út az unalmas rész, megoldva: inline validáció, 3-D Secure a folyamatba épített erős ügyfél-hitelesítéssel, olvasható routolási szabályzat alatt, és sandboxonkénti tesztkártyák az integrációs futtatásokhoz. A kripto fogadása sosem rontja a kártyás folyamatot.
12Apple Pay és Google Pay
A wallet módok gombok, nem projektek. Az Apple Pay és a Google Pay egyérintős lapként jelenik meg ugyanazon az oldalon, és eszköztokenekkel fizet — a valódi kártyaszám sosem jut el az oldalig — ugyanazon a rendelésen és ugyanazon a nyugtán keresztül. Bekapcsolásuk egy kapcsoló a fizetési módok képernyőjén.
13USDC, EUR-ra elszámolva
A kripto a checkoutnál megjelenített árfolyamon kap árat, és euróban számolódik el. A kereskedő sosem végez véletlenül tokenpozícióval; a könyvek egyetlen pénznemben maradnak.
14USDC három hálózaton
Az USDC mód egyetlen kapcsoló mögött fedi le az Ethereumot, a Base-t és a Solanát. Az ügyfél azon a hálózaton fizet, ahol a wallete van; a kereskedő oldalán semmi nem változik.
15Banki átutalás vIBAN-nal
Az átutalásos fizetés vIBAN hivatkozást hordoz, így a beérkező SEPA-fizetés már felépítésénél fogva azonosítja a rendelését. Kapcsold be azoknak az ügyfeleknek, akik számlát szeretnének, amit bankból fizethetnek ki, és az egyeztetés automatikus marad.
16Helyi fizetési módok, ahol számítanak
A kártyákon és wallet módokon túl a checkout azokat a számlaalapú és helyi fizetési módokat is tartalmazza, amelyeket egy európai vásárló elvár, az ügyfél országa szerint megjelenítve, nem egyetlen hosszú listába zsúfolva.
17Buy now, pay later
A BNPL ugyanabba a sorba kerül, mint minden más fizetési mód — az ügyfél részletekre bontja a fizetést, a kereskedő egyszerre kapja meg az összeget, a rendelés hivatkozása pedig nem változik. Egy kapcsoló, ugyanaz a nyugta, ugyanaz az egyeztetés.
18Fizetési módok, amelyek ismerik az ügyfelet
Az oldal azt a sorrendet állítja fel, amelyet az ügyfél valószínűleg használni fog — ország, nyelv, eszköz és az alapján, hogy fizetett-e már nálad —, így a releváns lehetőség az első, nem a negyedik.
19Az ő pénznemükben árazva, a tiédben elszámolva
Mutasd az összeget az ügyfél pénznemében, az átváltást megerősítés előtt kimondva, és számolj el mindenképp EUR-ban. Az ügyfél ismerős számot lát; a főkönyved csak egyet.
20Checkout az ő nyelvükön
A hosted oldal lokalizálja a címkéit, hibaüzeneteit és nyugtáit. Senki nem hagyja félbe a fizetést azért, mert a gomb rossz nyelven volt.
21Mentett kártyák és egykattintásos fizetés
A visszatérő ügyfél egy érintéssel fizet a tárolt kártyájával. A kártya nálunk van elzárva, és tokennel hivatkozunk rá, így a rendszereid hivatkozást tárolnak, sosem PAN-t — a második vásárlás pedig rövidebb, mint az első.
22Előfizetések és ismétlődő számlázás
Az ismétlődő terhelések az általad megadott ütemezés szerint futnak — összeg, intervallum, kezdet és vég — tokenizált kártyára. Minden ciklus saját rendelést és saját nyugtát hoz létre, így az előfizetés is sorról sorra egyeztethető, mint minden más.
23Újrapróbálkozások, amelyek megmentik a bevételt
Az ismétlődő terhelés soft decline-ját ütemezetten újrapróbáljuk, nem írjuk le, az ügyfelet pedig csak akkor értesítjük, ha az számít. A sikertelen megújítások többé nem néma lemorzsolódást jelentenek.
24Network tokenek és kártyafrissítések
A tárolt kártyákat network tokenként kezeljük, amelyek követik a kártyabirtokost az újrakibocsátásokon és lejáratokon át. Az előfizetés, amely korábban a kártya cseréjekor megszakadt, tovább terhel.
25API és fejlesztői felület
A rendelések API-n keresztül jönnek létre idempotencia-kulcsokkal — az újrapróbált kérés az eredeti eredményt adja vissza, sosem egy második terhelést —, a fejlesztői szekció pedig a kulcsokat és a dokumentációt tartalmazza. A checkout hosted; az integráció néhány endpoint, a beállítások mellett dokumentálva.
26Webhookok a rendelés életciklusán
A backended abban a pillanatban értesül a fizetésekről, ahogy megtörténnek: aláírt webhook-események a rendelés életciklusáról — kifizetve, sikertelen, visszatérítve — az aláírás-ellenőrzéssel a te oldaladon és a replay-védelemmel a miénken.
27Mobil SDK-k iOS-re és Androidra
A natív alkalmazások ugyanazt a checkoutot jelenítik meg az appon belül, ahelyett hogy a felhasználót böngészőbe dobnák. Az SDK viszi a fizetési módok logikáját, a wallet lapokat és a 3-D Secure-t; a rendelés és a nyugta pedig azok, amelyeket a backended már ismer.
A webshop-pluginok fejlesztő nélkül kötik össze a meglévő webshopot a Gateway-jel — telepítés, kulcsok beillesztése, egy teszttranzakció. Ugyanazok a rendelések ugyanabba a back office-ba érkeznek, mint az API-sak.
29Beágyazott mezők a saját oldaladon
Ha a fizetésnek a saját elrendezésedben kell megtörténnie, ágyazd be közvetlenül a fizetési mezőket: a beviteli mezők hosztolva vannak és PCI-hatókörben nálunk, a körülöttük lévő oldal teljesen a tiéd, a kártyaadat pedig sosem érinti a szervereidet.
30Egyszeri, többszöri, lejárati idővel
Egy link egyetlen fizetés után lezárulhat, vagy tovább gyűjthet — a demóban a workshop-helyre 3, a konzultációs órára 6 fizetés érkezett. A linkek alapértelmezés szerint 30 nap után lejárnak, és a lejárt link ezt ki is írja, nem mondja fel csendben a szolgálatot.
31Tesztmód
Az integrációs futtatások tesztmunkamenetekkel zajlanak, a sandbox kulcsok mellé kiadott kártyákkal, mielőtt bármi valódi mozogna. A folyamatok azonosak, így ami tesztben átmegy, az megy élesbe is.
32Olvasható routing
A kártyaforgalom olyan fogalmakkal írt routing szabályzatot követ, amelyeket ismer — kártyamárka, kibocsátó országa, pénznem, összeg — nem egy fekete dobozt. Hogy egy fizetés melyik útvonalon ment, ugyanazon a képernyőn látja, ahol magát a fizetést.
33Második próbálkozás az elveszett eladás előtt
A soft decline-t a rendszer ugyanazon a checkout munkamenetben alternatív útvonalon újrapróbálja, mielőtt a vásárló hibát látna. A megmentett fizetések többségéről a vásárló nem is tudta, hogy veszélyben volt.
34Elutasítások érthetően
A kibocsátói nyers kódokat olyan okokra fordítjuk, amelyekre az operátor tud reagálni — lejárt kártya, fedezethiány, kibocsátói kockázat — és csoportosítjuk őket, így a sok fizetésen átívelő minta mintaként látszik.
353-D Secure szabályként, nem súrlódásként
A fizetések többsége pusztán eszköz- és viselkedési jelek alapján átmegy; step-up ellenőrzés akkor jelenik meg, ha a szabályzat így kívánja. A szabályzatot Ön állítja be — mindig, kockázatalapon, vagy mentesítéssel, ahol a szabályok engedik — a hosztolt oldal pedig viszi a folyamatot.
36Egyetlen sor az egyeztetéshez
A checkout, a nyugta és az elszámolás ugyanazt a rendelésazonosítót viseli. Aki a 9F21-0716-ot keresi, egyetlen €49.00-s tételt talál — nem egy kártyás rekordot az egyik, egy kripto rekordot a másik rendszerben.
37Elszámolás és kifizetések
Az elszámolás ott van megadva, ahol beállítja: automatikus váltás EUR-ra, elszámolás a RO49 •••• 0421 számlára, napi kifizetés 23:00-kor. A számot, amelyet a könyvelő holnap lát, ma dönti el egy olyan képernyő, amelyet a kereskedő olvasni tud.
38Visszakövethető kifizetés
Minden kifizetés megnyílik azokra a rendelésekre, amelyek fedezték, tételesen kimutatott díjakkal. A banki sor egyezik egy exportálható listával, így a hónapzárás keresés, nem nyomozás.
39Részleges visszatérítések
A visszatérítés összege az eredeti terhelésig szerkeszthető — a panel mutatja a maximumot, és minden kisebb összeget részleges visszatérítésnek tekint. Egy rendelésre tíz részleges visszatérítés is egyetlen azonosítóhoz egyeztethető.
40Visszatérítési okok a nyilvántartásban
Minden visszatérítéshez kötelező ok és opcionális megjegyzés tartozik, és a megjegyzés tovább utazik: megjelenik az exportokban és a vásárló nyugtáján. Fél év múlva senkinek nem kell emlékeznie, miért kapott kárpótlást a 9F21-0716 rendelés.
41Nyugták kézbesítése
A nyugtákat e-mailben küldjük a vásárlónak, és azonnal letölthetők; a visszatérítési nyugták ugyanezt az utat járják. A kereskedőnek sosem kell nyugtasablont építenie.
42Visszavonás elszámolás előtt
A napi köteg előtti törlés feloldja az engedélyezési zárolást, és nem mozog pénz — nincs visszatérítés, nincs díj, és a vásárló kivonatán sincs mit magyarázni.
43Kockázatkezelés alapból bekapcsolva
A kártyás fizetések 3-D Secure-t futtatnak egy olvasható routing szabályzat alatt. A wallet-fizetések az eszköz saját hitelesítését viszik, a webhook-eseményeket pedig aláírás-ellenőrzés után tekintjük megbízhatónak.
44Szabályok az Ön szavaival
A szűrési szabályok mondatként olvashatók — X feletti összeg Y országból első alkalommal használt kártyán — és cselekszenek is: engedélyezés, kihívás vagy tiltás. A megbízható és tiltott kártyák, e-mail-címek és címek listái ugyanezen a képernyőn vannak.
45Sebesség- és eszközjelek
Az egy kártyáról, eszközről vagy címről érkező ismételt próbálkozásokat rate szabályok fogják meg, nem az, hogy valaki később észreveszi. A jelek a fizetésnél láthatók, nem egy pontszámban elásva.
46Viták a bizonyítékkal együtt
A chargeback a mögötte álló rendeléssel nyílik meg: engedélyezési eredmény, 3-D Secure kimenet, nyugta, kézbesítés, visszatérítési előzmények. Ugyanerről a képernyőről válaszolhat, a bizonyítékcsomag pedig a nyilvántartásból áll össze, nem emlékezetből.
47A kártyaadat sosem jut el Önhöz
A kártyaadatokat gyűjtő oldal a miénk: PCI-hatókörű és hosztolt. Akár a mi domainünkön, akár az Öné vagy az alkalmazásában fizet a vásárló, a szervere tokent és rendelésazonosítót lát — kártyaszámot soha.
48Titkosítva tárolva, az EU-ban
A fizetési adatok titkosítva tárolódnak, feldolgozásuk az EU-ban történik. Egy európai kereskedőnek az adatok helye válasz, nem lábjegyzet.
49Minden művelet nyilvántartva
Visszatérítések, módszerváltások, arculatváltások, kulcsrotációk — mindegyik auditnaplóba kerül az operátorral, az időbélyeggel és az indokkal. A privilegizált műveletekhez a futtatás előtt indokot kell megadni.
50Szerepkörök azoknak, akiknek kellenek
A pénzügy a kifizetéseket látja, a support a rendeléseket látja és visszatérít, a fejlesztők a kulcsokat és naplókat. A hozzáférés szerepkörönként jár, nem közös belépéssel.
51Ügyfélkatalógus
A fizetők ügyfélnézetbe gyűlnek — ki fizetett, milyen gyakran, milyen módszerrel — így a visszatérő vásárló egy rekord, nem az exportokban véletlenül egyező e-mail-címek.
52Keresés és CSV-export
Egy fizetést link vagy azonosító alapján megtalál a keresőmezőből; az aktuális nézetet CSV-be exportálhatja, ha a könyvelésnek kell. A back office abból indul ki, hogy a könyvelő kérdezni fog.
53A számok, napra és módszerre bontva
Forgalom, jóváhagyási arány, visszatérítések és módszermix a választott időszakra. Elég ahhoz, hogy kiderüljön, hová ment a pénz és melyik módszert érdemes népszerűsíteni — bármit exportálni nélkül.
54Az operátori nézet mögötte
A Gateway csatlakozik a Protocore Center rendszerhez: az ottani payment-links back office minden linket a hozzá tartozó elszámolási átutalással mutat, és egy open-in-Tracer linkkel a teljes nyomvonalhoz. Az ops csapata a checkouton át egészen a főkönyvig lát.
55Whitelabel vagy powered-by
A demó checkout az Arc Studio SRL-é: az ő nevük, az ő márkajelük, az ő rendelésük. Futtassa powered-by-Protocore lábléccel vagy teljesen whitelabel módon — az oldal így is, úgy is az Öné.
