Vi använder Google Analytics för trafikstatistik. Analyscookies placeras bara om du godkänner. Utan samtycke uppskattas statistiken utifrån cookielösa signaler. Cookiepolicy.
Gateway · Betalningar
Ett genomarbetat exempel går genom hela sidan — Arc Studio SRL, order 9F21-0716, €49.00. Kunden väljer kort, Apple Pay, Google Pay, USDC eller banköverföring, och handlarens sida av saken är densamma oavsett: en referens, ett kvitto, ett eurobelopp.
Trygghet
Metodfragmenteringen är handlarens problem, och den växer: en kortacquirer med egen dashboard, en plånboks-SDK med egen releasecykel, ett kryptoalternativ på en annan sida som inte stäms av någonstans. Varje ny metod är ännu en integration, ännu en uppsättning rapporter, ännu ett ställe där en betalning kan försvinna. Gateway slår ihop allt till en sida och en post.
Samma checkout på mobil — kort, plånböcker och USDC på en sida. · Kvittot — 52.95 USDC in, €49.00 avräknat, uttryckt rakt och tydligt.
Kort, Apple Pay, Google Pay, USDC, banköverföring och de lokala metoder dina köpare förväntar sig finns på samma hostade sida, ordnade efter vad kunden framför den sannolikt använder. Sidan anpassar sig till desktop, mobil och i appen; att ta emot en ny metod är en omkopplare, inte ett projekt.
Back office för länkar — varje länk med sin status, €2,304.50 inkasserat denna månad.
USDC prissätts till en kurs som visas på sidan innan kunden bekräftar, avräknas till euro och hamnar i samma utbetalning som kortintäkterna. Du håller aldrig en tokenposition, du bygger aldrig en treasury-funktion och din redovisning ser aldrig en andra valuta. Kvittot anger omräkningen på en rad — kunden betalade med krypto; böckerna säger €49.00.
En återbetalning på väg — mot ordern, motivering krävs, tillbaka via ursprunglig väg.
Allt hänger på ordern snarare än på betalmetoden. Order 9F21-0716 bär sina orderrader, sin bearbetningsavgift på €0.50, sin totalsumma, sitt auktoriseringsresultat, sitt kvitto och sina återbetalningar. Därför är avstämning en uppslagning, en tvist en enda skärm, och en återbetalning pekar på en order i stället för på ett kort, en plånbok eller en kedja.
Checkoutens varumärke — logotyp, färger, typsnitt och hörn, med liveförhandsvisning innan du sparar.
Kort valvas hos oss och refereras med token, så en återkommande kund betalar med ett tryck och dina system lagrar en referens i stället för ett kortnummer. Prenumerationer löper enligt det schema du definierar mot den token, gör egna omförsök vid mjuka nekanden och följer kortinnehavaren genom omutfärdanden — varje cykel ger en egen order och ett eget kvitto.
Metodkonfiguration — slå på metoder per checkout, med avräkning och routing bredvid.
Kortbetalningar följer en routingpolicy skriven i termer du känner igen, gör omförsök vid ett mjukt nekande på en alternativ väg innan kunden ser något fel, och stegar upp till 3-D Secure när policyn kräver det i stället för som standard. När en betalning verkligen nekas kommer orsaken på ett språk en operatör kan agera på, i stället för en rå utfärdarkod.
Ladda upp en logotyp, ställ in färger, typsnitt och hörn och förhandsgranska den riktiga checkouten innan du sparar. Kör den på vår domän, på din eller i din egen app — med en powered-by-sidfot eller fullt whitelabel. Demo-checkouten tillhör Arc Studio SRL, och den ser ut som deras.
Metoder
Varje metod som kassan erbjuder, vilka rails som ligger bakom och i vilken valuta pengarna landar. Kolumnen längst till höger är poängen: oavsett vad kunden väljer blir handlarens utbetalning ett enda eurobelopp.
Integration
Skapa en order med en idempotensnyckel, skicka kunden till den hostade kassan och ta emot ett signerat resultat. Hela integrationen är en handfull endpoints och en webhook.
Ingen integration alls — skapa en länk i back office, för engångsbruk eller insamlande, och skicka den. Betalningarna hamnar på samma ställe som API-betalningarna.
iOS och Android visar samma kassa nativt, så att kunden stannar i din app genom plånboksflöden och 3-D Secure.
Koppla en befintlig webbutik utan utvecklare: installera, klistra in nycklarna och gör en testbetalning med ett sandbox-kort.
Behåll din egen layout och bädda in betalfälten. De förblir hostade och PCI-omfattade hos oss, så kortuppgifter rör fortfarande aldrig dina servrar.
Integration
Din backend skapar en order via API: belopp, valuta, din referens.
Kunden väljer kort, plånbok eller USDC på den hostade sidan.
Medel verifieras och reserveras; 3-D Secure kopplas in först när policyn kräver det.
Debiteringen slutförs och köas för avräkning.
En signerad order.paid-webhook kommer in; verifiera signaturen och leverera.
Dagens ordrar samlas i en batch och betalas ut i EUR — en referens från kassa till bankrad.
Funktioner
Den värdbaserade checkouten visar kort, Apple Pay, Google Pay och USDC sida vid sida. Order 9F21-0716 står till vänster — tre orderrader, en bearbetningsavgift på €0.50, €49.00 att betala — och metodvalet till höger. Kunden väljer, sidan anpassar sig, handlaren integrerade en gång.
Samma checkout-URL anpassas till en mobilvy: ordern viks ihop till ett sammanfattningsfält, metodknapparna ligger kvar, kortformuläret behåller sina etiketter. Det som levereras på desktop levereras på mobil — och när du vill att betalningen ska ske i din egen app i stället för i en webbläsare visar SDK:erna för iOS och Android samma checkout nativt mot samma order.
Betalning med USDC slutar i ett kvitto som handlarens redovisningsansvarige kan läsa. Metod: 52.95 USDC på Base →︎ avveckling i EUR, till kursen som står på kvittot, 1 EUR = 1.0807 USDC. Referens 9F21-0716, mejlas till kunden och kan laddas ned direkt. Kunden betalade i krypto; böckerna visar €49.00.
Betallänkar får ett riktigt skrivbord: 8 länkar för Arc Studio SRL fördelade på betalda, aktiva och utgångna, med belopp, antal betalningar och status på varje rad. Korten ovanför håller räkningen — 4 aktiva länkar, €2,304.50 inbetalt den här månaden över 18 länkbetalningar, €49.00 betalt i dag. Skapa, sök, exportera, klart.
En återbetalning pekar på ordern, inte på en betalningsmetod. Panelen öppnas på 9F21-0716 med beloppet förifyllt till hela €49.00, en obligatorisk orsak och en valfri anteckning som hamnar i exporter och på kundens kvitto. Pengarna går tillbaka automatiskt via den ursprungliga betalvägen — kortåterbetalningar till kortet, USDC-ordrar som sin EUR-avveckling — vanligtvis inom 1–3 bankdagar.
Varumärkesprofilering är en inställningssida, inte ett konsultuppdrag: ladda upp en logotyp, ställ in accent-, text- och ytfärger, välj typsnitt och hörnstil. Liveförhandsvisningen återger din faktiska checkout — desktop eller mobil — innan du sparar, och accentfärgen styr fokus på betalknappen, statusmarkeringarna och den aktiva fliken. Kör den på checkout-värden som följer med din sandbox, eller på din egen domän.
Betalmetoder är reglage med leverantörer bakom: kort med 3-D Secure, Apple Pay och Google Pay som wallet-knappar, USDC på Ethereum, Base och Solana, SEPA-banköverföring via vIBAN-referens. Bredvid dem anger avvecklingspanelen villkoren rakt ut: kunderna ser omräkningen innan de bekräftar; du avvecklar alltid i EUR.
Skapa en order, omdirigera till den värdbaserade sidan, ta emot resultatet. Gateway sköter betalgränssnittet, metodlogiken och kvittona. Det finns ingen checkout-frontend för ditt team att bygga, patcha eller hålla aktuell när metoderna ändras.
Allt hänger på ordern, inte på betalningsmetoden. Order 9F21-0716 bär sina orderrader — en varumärkesidentitetssprint på €38.50, typsnittslicens på €6.00, expressleverans på €4.00 — en bearbetningsavgift på €0.50 och en summa. Hur den än betalas är den referensen det du frågar på, stämmer av och återbetalar mot.
Ändringar av metoder och profilering gäller nya checkout-sessioner — det står på skärmen där du sparar dem. En kund mitt i en betalning får aldrig sidan ändrad under händerna.
Kortflödet är den tråkiga delen, avklarad: validering direkt i fälten, 3-D Secure med stark kundautentisering inbyggd i flödet under en läsbar routningspolicy, och testkort per sandbox för integrationskörningar. Att ta emot krypto försämrar aldrig kortflödet.
Wallets är knappar, inte projekt. Apple Pay och Google Pay visas som enklicksark på samma sida och betalar med enhetstokens — det riktiga kortnumret når aldrig sidan — via samma order och samma kvitto. Att aktivera dem är ett reglage på metodskärmen.
Krypto prissätts till en kurs som visas i checkouten och avvecklas till euro. Handlaren råkar aldrig ut för en tokenposition; böckerna förblir i en valuta.
USDC-metoden omfattar Ethereum, Base och Solana bakom ett enda reglage. Kunden betalar på det nätverk deras wallet finns på; handlarens sida förändras inte.
Betalning via överföring bär en vIBAN-referens, så en inkommande SEPA-betalning identifierar sin order per konstruktion. Slå på den för kunder som vill ha en faktura de kan betala från banken, så förblir avstämningen automatisk.
Utöver kort och wallets har checkouten de konto-till-konto-metoder och lokala metoder som en europeisk köpare förväntar sig, presenterade efter kundens land i stället för i en enda lång lista.
BNPL ligger på samma metodrad som allt annat — kunden delar upp betalningen, handlaren får betalt en gång och orderreferensen ändras inte. Ett reglage, samma kvitto, samma avstämning.
Sidan ordnar metoderna efter vad kunden sannolikt använder — land, språk, enhet och om de har betalat hos dig förut — så att det relevanta alternativet kommer först, inte fyra.
Visa beloppet i kundens valuta med omräkningen angiven innan de bekräftar, och avveckla till EUR oavsett. Kunden ser ett bekant belopp; din huvudbok håller sig till ett.
Den värdbaserade sidan lokaliserar sina etiketter, felmeddelanden och kvitton. Ingen överger en betalning för att knappen var på fel språk.
En återkommande kund betalar med ett sparat kort med ett tryck. Kortet förvaras i valv hos oss och refereras via token, så dina system lagrar en referens, aldrig ett PAN — och det andra köpet går snabbare än det första.
Återkommande debiteringar körs enligt ett schema du definierar — belopp, intervall, start och slut — mot ett tokeniserat kort. Varje period ger en egen order och ett eget kvitto, så en prenumeration stäms av rad för rad som allt annat.
Ett mjukt avslag på en återkommande debitering provas om enligt schema i stället för att skrivas av, och kunden informeras bara när det spelar roll. Misslyckade förnyelser upphör att vara tyst kundavgång.
Sparade kort lagras som nätverkstokens och följer kortinnehavaren genom omutgivningar och utgångsdatum. Prenumerationen som förr brast när ett kort byttes fortsätter att debiteras.
Ordrar skapas via API med idempotensnycklar — en upprepad förfrågan ger det ursprungliga resultatet, aldrig en andra debitering — och utvecklarsektionen innehåller nycklarna och dokumentationen. Checkouten är värdbaserad; integrationen är en handfull endpoints, dokumenterade där inställningarna finns.
Din backend får veta om betalningar i samma ögonblick de sker: signerade webhook-händelser för orderns livscykel — betald, misslyckad, återbetald — med signaturverifiering hos dig och skydd mot återuppspelning hos oss.
Nativa appar visar samma checkout i appen i stället för att skicka användaren till en webbläsare. SDK:n sköter metodlogiken, wallet-arken och 3-D Secure; ordern och kvittot är samma som din backend redan känner till.
Plugins för webbshoppar kopplar en befintlig butik till Gateway utan utvecklare — installera, klistra in nycklarna, gör en testbetalning. Samma ordrar hamnar i samma back office som de som kommer via API.
När betalningen måste ske i din egen layout kan du bädda in betalfälten direkt: fälten hostas och PCI-omfattas hos oss, sidan runt omkring är helt din, och kortdata rör aldrig dina servrar.
En länk kan stängas efter en betalning eller fortsätta ta emot betalningar — demons workshopplats har tagit emot 3 betalningar, konsultationstimmen 6. Länkar går som standard ut efter 30 dagar, och utgångna länkar säger det tydligt i stället för att misslyckas tyst.
Integrationstester körs mot testsessioner med de kort som utfärdas tillsammans med dina sandbox-nycklar, innan något på riktigt flyttas. Flödena är identiska, så det som går igenom i test är det som går ut i produktion.
Korttrafik följer en routingpolicy som är skriven i termer du känner igen — kortvarumärke, utfärdarland, valuta, belopp — i stället för en black box. Du ser vilken route en betalning tog, på samma skärm som visar betalningen.
En mjuk avvisning provas på nytt via en alternativ route inom samma checkout-session, innan kunden ser något fel. De flesta räddade betalningar är sådana som kunden aldrig visste var i riskzonen.
Råa utfärdarkoder översätts till orsaker som en operatör kan agera på — utgånget kort, otillräckliga medel, utfärdarrisk — och grupperas så att ett mönster över många betalningar syns som just ett mönster.
De flesta betalningar går igenom enbart på enhets- och beteendesignaler; en step-up-verifiering visas när policyn kräver det. Du bestämmer policyn — alltid, riskbaserat eller undantag där reglerna tillåter — och den hostade sidan sköter flödet.
Checkout, kvitto och avräkning har samma orderreferens. Den som matchar 9F21-0716 hittar en enda post på €49.00 — inte en kortpost i ett system och en kryptopost i ett annat.
Avräkningen anges där du konfigurerar den: automatisk växling till EUR, avräkning till RO49 •••• 0421, daglig utbetalning kl. 23:00. Siffran som redovisaren ser i morgon bestäms på en skärm som handlaren kan läsa i dag.
Varje utbetalning öppnas till de ordrar som finansierade den, med avgifterna specificerade. Bankraden matchar en lista du kan exportera, så månadsavslutet blir ett uppslag i stället för en utredning.
Återbetalningsbeloppet kan redigeras upp till det ursprungliga beloppet — panelen visar maxbeloppet och behandlar allt lägre som en delåterbetalning. Tio delåterbetalningar på en order stäms ändå av mot en enda referens.
Varje återbetalning har en obligatorisk orsak och en valfri anteckning, och anteckningen följer med: den syns i exporter och på kundens kvitto. Sex månader senare behöver ingen minnas varför order 9F21-0716 gottgjordes.
Kvitton skickas med e-post till kunden och kan laddas ner direkt, och återbetalningskvitton följer samma väg. Handlaren behöver aldrig bygga en kvittomall.
Om du avbryter före dagens batch släpps reservationen på auktoriseringen och inga pengar flyttas — ingen återbetalning, ingen avgift, inget på kundens kontoutdrag att förklara.
Kortbetalningar körs med 3-D Secure enligt en routingpolicy du kan läsa. Plånboksbetalningar bär enhetens egen autentisering, och webhook-händelser signaturverifieras innan de litas på.
Screeningregler läser som meningar — belopp över X från land Y med ett förstagångskort — och agerar på dem: tillåt, utmana eller blockera. Listor över betrodda och blockerade kort, e-postadresser och adresser ligger bakom samma skärm.
Upprepade försök från ett kort, en enhet eller en adress fångas av hastighetsregler i stället för att någon märker det i efterhand. Signalerna visas på betalningen, inte begravda i en poäng.
En chargeback öppnas tillsammans med ordern bakom den: auktoriseringsresultat, 3-D Secure-utfall, kvitto, leverans, återbetalningshistorik. Svara från den skärmen, så sammanställs bevispaketet från loggen och inte ur minnet.
Sidan som samlar in kortuppgifter är vår, PCI-omfattad och hostad. Oavsett om kunden betalar på vår domän, på din eller i din app ser dina servrar en token och en orderreferens — aldrig ett kortnummer.
Betalningsdata krypteras i vila och behandlas inom EU. För en europeisk handlare är var datan finns ett svar, inte en fotnot.
Återbetalningar, byten av metod, ändringar av varumärkning, nyckelrotationer — allt skrivs till ett granskningsspår med operatör, tidsstämpel och orsak. Behörighetskrävande åtgärder kräver en orsak innan de körs.
Ekonomi ser utbetalningar, support ser ordrar och gör återbetalningar, utvecklare ser nycklar och loggar. Åtkomst ges per roll i stället för genom att dela en inloggning.
Betalare samlas i en kundvy — vem som betalade, hur ofta, med vilken metod — så att en återkommande kund är en post, inte en slump av matchande e-postadresser i exporter.
Hitta en betalning via länk eller referens i sökrutan; exportera den aktuella vyn till CSV när bokföringen behöver det. Backoffice utgår från att en redovisare kommer att fråga.
Volym, godkännandegrad, återbetalningar och metodmix, över den period du väljer. Tillräckligt för att svara på vart pengarna tog vägen och vilken metod som är värd att lyfta fram — utan att exportera något.
Gateway kopplas in i Protocore Center: backoffice för betalningslänkar visar där varje länk med tillhörande avräkningsöverföring och en länk som öppnas i Tracer för hela spårningen. Ditt driftteam ser genom checkouten ända ner till huvudboken.
Demo-checkouten tillhör Arc Studio SRL: deras namn, deras märke, deras order. Kör den med en powered-by-Protocore-sidfot eller helt whitelabel — sidan upplevs i båda fallen som din.
FAQ
Kortbetalningar går i två steg: auktorisering reserverar medlen vid köpet, avräkning flyttar dem. Gateway fångar automatiskt, samlar dagens ordrar i en batch och betalar ut i EUR till ditt namngivna konto vid den dagliga utbetalningstid som anges i inställningarna.
Tidpunkten. Före avräkning frigör en annullering reservationen och inga pengar flyttas. Efter avräkning blir det en återbetalning — utfärdad mot ordern, hel eller delvis, och den går tillbaka via den ursprungliga betalningsmetoden med orsaken registrerad.
Som policy, inte som friktion som standard. De flesta flöden går igenom enbart på enhets- och beteendedata; en extra verifiering visas bara när routingpolicyn kräver det. Du bestämmer policyn — den hostade sidan sköter flödet.
Euro. USDC-beloppet prissätts på sidan innan kunden bekräftar, avräknas till EUR till angiven kurs och kvittot registrerar växlingen. Kassa, kvitto och avräkning delar en orderreferens — du håller aldrig någon tokenposition.
Ordern är din bevismapp. Auktoriseringsresultat, kvitto, återbetalningshistorik och webhook-leveranser hänger alla på en referens — ett enda uppslag besvarar tvisten, och en återbetalning från samma vy är ofta den snabbare lösningen.
Nej. Ordrar skapas med idempotensnycklar, så en omskickad förfrågan returnerar det ursprungliga resultatet i stället för en andra debitering — och webhooks signeras med skydd mot replay på vägen tillbaka.
Sidan som samlar in kortuppgifter är vår — hostad och PCI-omfattad hos oss. Dina servrar tar emot en token och en orderreferens, aldrig ett kortnummer. Det gäller oavsett om kunden betalar på vår domän, på din, i din app eller via betalfält inbäddade i din egen layout.
Ja. Kör den på kassavärden som följer med din sandbox, på en egen domän eller inbäddad på din sida med hostade betalfält. Branding — logotyp, färger, typsnitt, hörn — görs i en inställningsvy med live-förhandsvisning, och sidfoten är antingen "powered by" eller helt whitelabel, som du väljer.
Kort förvaras hos oss som nätverkstokens; dina system behåller en referens. En prenumeration debiterar den token enligt ditt schema, försöker själv igen vid mjuka nekanden och följer kortinnehavaren genom kortbyten. Varje cykel skapar en egen order och ett eget kvitto, så en prenumeration kan stämmas av rad för rad.
Beloppet i sin egen valuta, med växlingen angiven innan de bekräftar, och kassan på sitt eget språk. Du avräknas fortfarande i EUR. Samma princip som med USDC: kundens sida anpassas, din reskontra förblir i en valuta.
Din del är en kundfordran i euro. Gateway sköter kryptodelen — prissättning, betalningen on-chain och växlingen — och det som når ditt konto är EUR från en reglerad avräkningsväg, med tillämpad kurs angiven på kvittot. Du förvarar inga tokens, driver ingen plånbok och håller ingen position, eftersom växlingen sker före avräkningen, inte efter.
En betalningslänk fungerar samma dag du har ett konto. En API-integration är en orderendpoint, en omdirigering och en signerad webhook — de flesta team har den igång i test samma vecka och går över till live när de gjort en testbetalning från början till slut. Butiksplugins kräver ingen utveckling alls.
Ja — kör båda. Rikta nya ordrar till Gateway medan den gamla leverantören avräknar och återbetalar sina egna, eftersom återbetalningar alltid går tillbaka via den rail som tog emot betalningen. Sparade kort migreras som tokens, så dina prenumeranter behöver inte ange kortuppgifter igen.
Orderanropet och webhook-hanteraren. Betalsidan, metodlogiken, plånboksflöden, 3-D Secure, kvitton och varje ny metod som läggs till senare håller vi aktuella — det är poängen med en hostad kassa.
Priser
Gå live utan plattformsavgift — Gateway tjänar på de betalningar som behandlas, så kostnaden följer volymen genom checkouten.
Kör checkout under ditt eget varumärke med en licens anpassad efter de spår du aktiverar och den genomströmning du planerar för.
Ditt varumärke på betalsidan, våra spår under, drivet åt dig — omfattningen följer de betalmetoder du slår på.
Kostnaden följer volymen genom checkouten och de spår du aktiverar — kort, plånbok och USDC-avräkning. Välj fristående eller fullt whitelabel.
Utvärdera
Vi går igenom det genomarbetade exemplet med dig — Arc Studio SRL, order 9F21-0716 — som betalar med kort, plånbok och USDC, och visar handlarens back office bakom.
En testhandlare med API-nycklar, så att ditt team kan skapa ordrar, köra den hostade checkouten och ta emot signerade resultat hela vägen.
Order-API:et, webhooken order.paid och integrationsguiden — allt som behövs för att peka en checkout mot Gateway i stället för att bygga en egen.
Den hostade sidan med din logotyp, dina färger och ditt typsnitt, så att du ser din egen checkout innan du går live.
Vidare läsning
Körs fristående eller som whitelabel — ditt varumärke på checkouten, våra spår under.
PoS delar Gateways ordermodell i kassan, vIBAN ger banköverföringsordrarna självidentifierande referenser, Chain växlar USDC-betalningar till EUR, Center är operatörskonsolen bakom kassan och Agents tillämpar samma ordermodell på betalningar som initieras av mjukvara under mänsklig policy.
Allt ovan körs i produktionsdemos som vi gärna går igenom med dig – fristående, som whitelabel eller som en samlad plattform. Berätta vad ni bygger så visar vi den kortaste vägen dit.
