Vi bruker Google Analytics til trafikkstatistikk. Analyseinformasjonskapsler settes bare hvis du godtar. Uten samtykke estimeres statistikken fra signaler uten informasjonskapsler. Retningslinjer for informasjonskapsler.
Gateway · Betalinger
Et eksempel går gjennom hele siden — Arc Studio SRL, ordre 9F21-0716, €49.00. Kunden velger kort, Apple Pay, Google Pay, USDC eller bankoverføring, og forhandlerens side av saken er den samme uansett: én referanse, én kvittering, ett eurobeløp.
Garantier
Metodefragmenteringen er forhandlerens problem, og den vokser: en kortprosessor med eget dashbord, en lommebok-SDK med egen utgivelsessyklus, et kryptoalternativ som ligger på en annen side og ikke avstemmes noe sted. Hver ny metode er enda en integrasjon, enda et sett rapporter, enda et sted en betaling kan forsvinne. Gateway samler alt i én side og én post.
Samme checkout på mobil — kort, lommebøker og USDC på én side. · Kvitteringen — 52.95 USDC inn, €49.00 gjort opp, oppgitt rett fram.
Kort, Apple Pay, Google Pay, USDC, bankoverføring og de lokale metodene kundene dine forventer ligger på samme hostede side, sortert etter hva kunden foran skjermen mest sannsynlig bruker. Siden tilpasser seg desktop, mobil og app; å ta imot en ny metode er en bryter, ikke et prosjekt.
Backoffice for lenker — hver lenke med status, €2,304.50 innkrevd denne måneden.
USDC prises til en kurs som vises på siden før kunden bekrefter, gjøres opp i euro og havner i samme utbetaling som kortinntektene. Du holder aldri en tokenposisjon, du trenger ingen treasury-funksjon, og regnskapsføreren din ser aldri en ekstra valuta. Kvitteringen oppgir vekslingen på én linje — kunden betalte med krypto; regnskapet sier €49.00.
En refusjon underveis — mot ordren, begrunnelse påkrevd, tilbake via opprinnelig rute.
Alt henger på ordren, ikke på betalingsmetoden. Ordre 9F21-0716 bærer ordrelinjene, behandlingsgebyret på €0.50, totalen, autorisasjonsresultatet, kvitteringen og refusjonene. Derfor er avstemming et oppslag, en tvist én skjerm, og en refusjon peker på en ordre i stedet for på et kort, en lommebok eller en kjede.
Checkout-profilering — logo, farger, skrift og hjørner, forhåndsvist live før du lagrer.
Kort lagres i hvelvet hos oss og refereres med token, så en returnerende kunde betaler med ett trykk, og systemene dine lagrer en referanse i stedet for et kortnummer. Abonnementer kjører på timeplanen du definerer mot den tokenen, prøver myke avslag på nytt av seg selv og følger kortholderen gjennom utskiftinger — hver syklus gir sin egen ordre og sin egen kvittering.
Metodekonfigurasjon — slå metoder av og på per checkout, med oppgjør og ruting ved siden av.
Korttrafikken følger en rutingpolicy skrevet i termer du kjenner igjen, prøver et mykt avslag på nytt over en alternativ rute før kunden ser en feil, og trapper opp til 3-D Secure når policyen krever det, ikke som standard. Når en betaling virkelig blir avvist, kommer årsaken på et språk en operatør kan handle på, ikke som en rå utstederkode.
Last opp en logo, velg farger, skrift og hjørner, og forhåndsvis den ekte checkouten før du lagrer. Kjør den på vårt domene, på ditt eller inne i din egen app — med «powered by»-bunntekst eller fullt whitelabel. Demo-checkouten tilhører Arc Studio SRL, og den fremstår som deres.
Metoder
Alle betalingsmetoder som vises i checkout, skinnegangen bak dem og valutaen de lander i. Poenget står i høyre kolonne: uansett hva kunden velger, er utbetalingen til forhandleren ett eurobeløp.
Integrasjon
Opprett en ordre med en idempotensnøkkel, send kunden til hostet checkout og motta et signert resultat. Hele integrasjonen er en håndfull endepunkter og én webhook.
Ingen integrasjon i det hele tatt – opprett en lenke i back office, til engangsbruk eller innsamling, og send den. Betalingene havner på samme sted som API-betalingene.
iOS og Android viser samme checkout native, slik at kunden blir i appen din gjennom lommebokark og 3-D Secure.
Koble til en eksisterende nettbutikk uten utvikler: installer, lim inn nøklene og gjennomfør en testbetaling med et sandbox-kort.
Behold din egen layout og bygg inn betalingsfeltene. De forblir hostet og PCI-omfattet hos oss, så kortdata berører fortsatt aldri serverne dine.
Integrasjon
Backend-en din oppretter en ordre via API: beløp, valuta, din referanse.
Kunden velger kort, lommebok eller USDC på den hostede siden.
Dekning verifiseres og reserveres; 3-D Secure kobles inn bare når policyen krever det.
Belastningen fullføres og settes i kø for oppgjør.
En signert order.paid-webhook kommer inn; verifiser signaturen og lever.
Dagens ordrer samles i en batch og utbetales i EUR – én referanse fra checkout til banklinje.
Funksjoner
Den hostede checkouten setter kort, Apple Pay, Google Pay og USDC side om side. Ordre 9F21-0716 står til venstre — tre ordrelinjer, et behandlingsgebyr på €0.50, €49.00 til betaling — og valg av metode til høyre. Kunden velger, siden tilpasser seg, og selgeren integrerte én gang.
Den samme checkout-URL-en tilpasser seg et mobilformat: ordren foldes sammen til en sammendragslinje, metodeknappene blir stående, og kortskjemaet beholder etikettene sine. Det som leveres på desktop, leveres på mobil — og når betalingen skal skje i din egen app i stedet for i en nettleser, viser iOS- og Android-SDK-ene den samme checkouten native mot den samme ordren.
Betaling med USDC ender i en kvittering som selgerens regnskapsfører kan lese. Metode: 52.95 USDC på Base →︎ oppgjør i EUR, til kursen som står på kvitteringen, 1 EUR = 1.0807 USDC. Referanse 9F21-0716, sendt på e-post til kunden og tilgjengelig for nedlasting på stedet. Kunden betalte med krypto; regnskapet sier €49.00.
Betalingslenker får et ordentlig kontrollbord: 8 lenker for Arc Studio SRL fordelt på betalt, aktiv og utløpt, med beløp, antall betalinger og status på hver rad. Kortene øverst holder poengene — 4 aktive lenker, €2,304.50 innkrevd denne måneden fra 18 lenkebetalinger, €49.00 betalt i dag. Opprett, søk, eksporter, ferdig.
En refusjon peker på ordren, ikke på en betalingsmetode. Skuffen åpnes på 9F21-0716 med beløpet forhåndsutfylt til hele €49.00, en påkrevd begrunnelse og et valgfritt notat som havner i eksporter og på kundens kvittering. Pengene går automatisk tilbake via den opprinnelige betalingsskinnegangen — kortrefusjoner til kortet, USDC-ordrer som sitt EUR-oppgjør — vanligvis innen 1–3 virkedager.
Branding er en innstillingsside, ikke et konsulentoppdrag: last opp en logo, sett aksent-, tekst- og flatefarger, og velg skrifttype og hjørnestil. Forhåndsvisningen viser din faktiske checkout — desktop eller mobil — før du lagrer, og aksentfargen styrer fokus på betalingsknappen, statusmarkeringer og aktiv fane. Kjør den på checkout-verten som følger med sandkassen din, eller på ditt eget domene.
Betalingsmetoder er brytere med leverandører bak: kort med 3-D Secure, Apple Pay og Google Pay som wallet-knapper, USDC på Ethereum, Base og Solana, SEPA-bankoverføring via vIBAN-referanse. Ved siden av dem sier oppgjørspanelet det rett ut: kundene ser omregningen før de bekrefter; du gjør alltid opp i EUR.
Opprett en ordre, send kunden videre til den hostede siden, motta resultatet. Gateway tar seg av betalingsgrensesnittet, metodelogikken og kvitteringene. Teamet ditt slipper å bygge, patche eller vedlikeholde en checkout-frontend når metodene endrer seg.
Alt henger på ordren, ikke på betalingsmetoden. Ordre 9F21-0716 har sine ordrelinjer — en brand identity-sprint til €38.50, skriftlisensiering til €6.00, ekspresslevering til €4.00 — et behandlingsgebyr på €0.50 og én total. Uansett hvordan den betales, er den referansen du spør etter, avstemmer og refunderer mot.
Endringer i metoder og branding gjelder nye checkout-økter — og det står på skjermen der du lagrer dem. En kunde midt i en betaling får aldri siden endret under hendene.
Kortflyten er den kjedelige delen, løst: validering underveis, 3-D Secure med sterk kundeautentisering innebygd i flyten under en lesbar rutingpolicy, og testkort per sandkasse for integrasjonstester. Å ta imot krypto gjør aldri kortflyten dårligere.
Wallets er knapper, ikke prosjekter. Apple Pay og Google Pay vises som ettrykksark på samme side og betaler med enhetstokens — det ekte kortnummeret når aldri siden — gjennom samme ordre og samme kvittering. Å aktivere dem er en bryter på metodeskjermen.
Krypto prises til en kurs som vises i checkout, og gjøres opp i euro. Selgeren ender aldri opp med en tokenposisjon ved et uhell; regnskapet holdes i én valuta.
USDC-metoden dekker Ethereum, Base og Solana bak én enkelt bryter. Kunden betaler på nettverket walleten bor på; selgerens side endres ikke.
Betaling via overføring har en vIBAN-referanse, slik at en innkommende SEPA-betaling identifiserer ordren sin av seg selv. Slå den på for kundene som vil ha en faktura de kan betale fra banken, så forblir avstemmingen automatisk.
Utover kort og wallets har checkouten de konto-til-konto-metodene og lokale metodene en europeisk kjøper forventer å se, presentert etter kundens land i stedet for dumpet i én lang liste.
BNPL ligger på samme metoderad som alt annet — kunden deler opp betalingen, selgeren får betalt én gang, og ordrereferansen endres ikke. Én bryter, samme kvittering, samme avstemming.
Siden rangerer metodene etter det kunden sannsynligvis bruker — land, språk, enhet og om de har betalt hos deg før — slik at det relevante alternativet kommer først, ikke som nummer fire.
Vis beløpet i kundens valuta med omregningen oppgitt før de bekrefter, og gjør opp i EUR uansett. Kunden ser et kjent tall; hovedboken din har ett.
Den hostede siden lokaliserer etiketter, feilmeldinger og kvitteringer. Ingen avbryter en betaling fordi knappen var på feil språk.
En tilbakevendende kunde betaler med et lagret kort med ett trykk. Kortet lagres i hvelvet vårt og refereres til med token, så systemene dine lagrer en referanse, aldri et PAN — og det andre kjøpet går raskere enn det første.
Gjentakende belastninger kjøres etter en plan du definerer — beløp, intervall, start og slutt — mot et tokenisert kort. Hver syklus gir sin egen ordre og sin egen kvittering, så et abonnement avstemmes linje for linje som alt annet.
En soft decline på en gjentakende belastning forsøkes på nytt etter en plan i stedet for å bli avskrevet, og kunden får bare beskjed når det betyr noe. Mislykkede fornyelser er ikke lenger stille churn.
Lagrede kort oppbevares som nettverkstokens og følger kortinnehaveren gjennom utskiftinger og utløp. Abonnementet som pleide å brekke når et kort ble byttet, fortsetter å trekke.
Ordrer opprettes via API med idempotensnøkler — en gjentatt forespørsel gir det opprinnelige resultatet, aldri en ny belastning — og utviklerseksjonen har nøklene og dokumentasjonen. Checkouten er hostet; integrasjonen er en håndfull endepunkter, dokumentert der innstillingene ligger.
Backenden din får vite om betalinger i det øyeblikket de skjer: signerte webhook-hendelser for ordrens livssyklus — betalt, mislykket, refundert — med signaturverifisering hos deg og beskyttelse mot replay hos oss.
Native apper viser den samme checkouten i appen i stedet for å sende brukeren ut i en nettleser. SDK-en har metodelogikken, wallet-arkene og 3-D Secure; ordren og kvitteringen er de samme som backenden din allerede kjenner.
Plugins for nettbutikkløsninger kobler en eksisterende butikk til Gateway uten utvikler — installer, lim inn nøklene, ta en testbetaling. De samme ordrene havner i samme backoffice som API-ordrene.
Når betalingen må skje i ditt eget oppsett, bygger du inn betalingsfeltene direkte: inputfeltene er hostet og PCI-avgrenset hos oss, siden rundt er helt din, og kortdata berører aldri serverne dine.
En lenke kan lukkes etter én betaling eller fortsette å ta imot betalinger — workshopplassen i demoen har fått 3 betalinger, konsultasjonstimen 6. Lenker utløper automatisk etter 30 dager som standard, og utløpte lenker sier fra om det i stedet for å feile i det stille.
Integrasjonskjøringer skjer mot testsesjoner med kortene som følger med sandbox-nøklene dine, før noe ekte flyttes. Flytene er identiske, så det som består i test, er det som går i produksjon.
Kortbetalinger følger en rutingpolicy skrevet i begreper du kjenner igjen — kortmerke, utstederland, valuta, beløp — i stedet for en svart boks. Du ser hvilken rute en betaling tok, fra samme skjermbilde som viser betalingen.
Et soft decline prøves på nytt via en alternativ rute i samme checkout-sesjon, før kunden ser en feil. De fleste reddede betalinger er betalinger kunden aldri visste var i faresonen.
Rå utstederkoder oversettes til årsaker en operatør kan handle på — utløpt kort, utilstrekkelig saldo, utstederrisiko — og grupperes slik at et mønster på tvers av mange betalinger synes som et mønster.
De fleste betalinger går gjennom på enhets- og atferdssignaler alene; en step-up-utfordring vises når policyen krever det. Du setter policyen — alltid, risikobasert eller unntatt der reglene tillater det — og den hostede siden håndterer flyten.
Checkout, kvittering og oppgjør har samme ordrereferanse. Den som slår opp 9F21-0716, finner én post på €49.00 — ikke en kortpost i ett system og en kryptopost i et annet.
Oppgjør angis der du konfigurerer det: auto-konverter til EUR, oppgjør til RO49 •••• 0421, utbetaling daglig kl. 23:00. Tallet regnskapsføreren ser i morgen, bestemmes på en skjerm forhandleren kan lese i dag.
Hver utbetaling åpner seg til ordrene som finansierte den, med spesifiserte gebyrer. Banklinjen samsvarer med en liste du kan eksportere, så månedsavslutningen blir et oppslag i stedet for en etterforskning.
Refusjonsbeløpet kan redigeres opp til det opprinnelige beløpet — skuffen viser maksimum og behandler alt mindre som en delrefusjon. Ti delrefusjoner mot én ordre avstemmes fortsatt mot én referanse.
Hver refusjon har en obligatorisk årsak og et valgfritt notat, og notatet følger med: det vises i eksporter og på kundens kvittering. Seks måneder senere trenger ingen å huske hvorfor ordre 9F21-0716 ble gjort opp.
Kvitteringer sendes på e-post til kunden og kan lastes ned med en gang, og refusjonskvitteringer følger samme vei. Forhandleren trenger aldri å lage en kvitteringsmal.
Annullering før dagens batch frigir reservasjonen på autorisasjonen, og ingen penger flyttes — ingen refusjon, ingen gebyr, ingenting på kundens kontoutskrift som må forklares.
Kortbetalinger kjører 3-D Secure under en rutingpolicy du kan lese. Lommebokbetalinger bærer enhetens egen autentisering, og webhook-hendelser signaturverifiseres før de stoles på.
Screeningregler leses som setninger — beløp over X fra land Y på et kort brukt for første gang — og handler deretter: tillat, utfordre eller blokker. Lister over pålitelige og blokkerte kort, e-postadresser og adresser ligger bak samme skjerm.
Gjentatte forsøk fra ett kort, én enhet eller én adresse fanges opp av ratereglene i stedet for at noen legger merke til det senere. Signalene vises på betalingen, ikke begravd i en score.
En chargeback åpnes med ordren bak: autorisasjonsresultat, 3-D Secure-utfall, kvittering, levering, refusjonshistorikk. Svar fra det skjermbildet, så settes bevispakken sammen fra loggen i stedet for fra hukommelsen.
Siden som samler inn kortopplysninger, er vår, PCI-omfattet og hostet. Enten kunden betaler på vårt domene, ditt eller i appen din, ser serverne dine et token og en ordrereferanse — aldri et kortnummer.
Betalingsdata er kryptert i hvile og behandles i EU. For en europeisk forhandler er det et svar, ikke en fotnote, hvor dataene ligger.
Refusjoner, endringer av betalingsmetode, endringer i merkevarebygging, nøkkelrotasjoner — alt skrives til et revisjonsspor med operatør, tidsstempel og årsak. Privilegerte handlinger krever en årsak før de kjøres.
Økonomi ser utbetalinger, support ser ordrer og utsteder refusjoner, utviklere ser nøkler og logger. Tilgang gis per rolle i stedet for ved å dele én pålogging.
Betalere samles i en kundevisning — hvem som betalte, hvor ofte, med hvilken metode — slik at en gjenganger er en post, ikke et sammentreff av like e-postadresser i eksporter.
Finn en betaling via lenke eller referanse i søkefeltet; eksporter gjeldende visning til CSV når regnskapet trenger det. Back office forutsetter at en regnskapsfører kommer til å spørre.
Volum, godkjenningsrate, refusjoner og metodefordeling, over perioden du velger. Nok til å svare på hvor pengene gikk og hvilken metode som er verdt å fremme — uten å eksportere noe.
Gateway kobles til Protocore Center: back office for betalingslenker der viser hver lenke med oppgjørsoverføringen knyttet til og en åpne-i-Tracer-lenke for full sporing. Driftsteamet ditt ser gjennom checkout helt ned til hovedboken.
Demo-checkouten tilhører Arc Studio SRL: deres navn, deres merke, deres ordre. Kjør den med en «powered by Protocore»-bunntekst eller fullt whitelabel — uansett fremstår siden som din.
FAQ
Kortbetalinger går i to trinn: autorisasjon reserverer beløpet ved kjøpet, oppgjør flytter det. Gateway fanger automatisk, samler dagens ordrer i en batch og utbetaler i EUR til din navngitte konto på det daglige utbetalingstidspunktet som er satt i innstillingene.
Tidspunktet. Før oppgjør frigir en kansellering autorisasjonsreservasjonen, og ingen penger flyttes. Etter oppgjør er det en refusjon – utstedt mot ordren, hel eller delvis, og sendt tilbake via den opprinnelige betalingsmetoden med årsaken registrert.
Som policy, ikke som standard friksjon. De fleste flyt går gjennom på enhets- og atferdsdata alene; en step-up-utfordring dukker bare opp når rutingpolicyen krever det. Du setter policyen – den hostede siden bærer flyten.
Euro. USDC-beløpet prises på siden før kunden bekrefter, gjøres opp til EUR til oppgitt kurs, og kvitteringen registrerer konverteringen. Checkout, kvittering og oppgjør deler én ordrereferanse – du holder aldri en tokenposisjon.
Ordren er bevismappen din. Autorisasjonsresultat, kvittering, refusjonshistorikk og webhook-levering henger alle på én referanse – ett oppslag besvarer tvisten, og en refusjon fra samme skjermbilde er ofte den raskeste løsningen.
Nei. Ordrer opprettes med idempotensnøkler, så en gjentatt forespørsel returnerer det opprinnelige resultatet i stedet for en ny belastning – og webhooks signeres med replay-beskyttelse på veien tilbake.
Siden som samler inn kortopplysninger er vår – hostet og PCI-omfattet hos oss. Serverne dine mottar en token og en ordrereferanse, aldri et kortnummer. Det gjelder enten kunden betaler på vårt domene, på ditt, i appen din eller via betalingsfelt innebygd i din egen layout.
Ja. Kjør den på checkout-verten som følger med sandboxen din, på et eget domene, eller innebygd på siden din med hostede betalingsfelt. Branding – logo, farger, skrifttype, hjørner – styres fra et innstillingsbilde med live forhåndsvisning, og bunnteksten er enten «powered by» eller fullt whitelabel, som du velger.
Kort lagres hos oss som nettverkstokens, og systemene dine beholder en referanse. Et abonnement belaster tokenet etter planen du setter, prøver egne myke avslag på nytt og følger kortholderen gjennom kortutskiftinger. Hver syklus oppretter sin egen ordre og kvittering, så et abonnement avstemmes linje for linje.
Beløpet i deres egen valuta, med konverteringen oppgitt før de bekrefter, og checkout på deres språk. Du gjør fortsatt opp i EUR. Samme prinsipp som med USDC: kundens side tilpasser seg, hovedboken din holder seg i én valuta.
Din side er en eurofordring. Gateway håndterer kryptoleddet – prising, betalingen on-chain og konvertering – og det som når kontoen din er EUR fra en regulert oppgjørsvei, registrert på kvitteringen med kursen som er brukt. Du oppbevarer ikke tokens, driver ikke en lommebok og holder ingen posisjon, fordi konverteringen skjer før oppgjøret, ikke etter.
En betalingslenke fungerer samme dag du har en konto. En API-integrasjon er et ordreendepunkt, en redirect og én signert webhook – de fleste team har den kjørende i test samme uke og går live når de har gjennomført en testbetaling fra ende til ende. Butikkplugins hopper over utviklingen helt.
Ja – kjør begge. Send nye ordrer til Gateway mens den gamle leverandøren gjør ferdig oppgjør og refusjoner for sine egne, siden refusjoner alltid går tilbake via den skinnegangen som tok imot betalingen. Lagrede kort migreres som tokens, så abonnentene dine slipper å taste inn kortopplysninger på nytt.
Ordrekallet og webhook-handleren. Betalingssiden, metodelogikken, lommebokark, 3-D Secure, kvitteringer og alle nye metoder som legges til senere holder vi oppdatert – det er hele poenget med hostet checkout.
Priser
Gå live uten plattformavgift — gatewayen tjener på betalingene den behandler, så kostnaden følger volumet som går gjennom checkout.
Drift checkout under ditt eget merke på en lisens tilpasset sporene du aktiverer og gjennomstrømmingen du planlegger for.
Ditt merke på betalingssiden, våre spor nedenunder, drevet for deg — omfanget følger betalingsmetodene du slår på.
Kostnaden følger volumet som går gjennom checkout og sporene du aktiverer — kort, lommebok og USDC-oppgjør. Velg frittstående eller fullt whitelabel.
Vurder
Vi går gjennom eksempelet sammen med deg — Arc Studio SRL, ordre 9F21-0716 — betalt med kort, lommebok og USDC, og viser forhandlerens backoffice bak.
En testforhandler med API-nøkler, slik at teamet ditt kan opprette ordrer, kjøre den hostede checkouten og motta signerte resultater fra ende til ende.
Ordre-API-et, webhooken order.paid og integrasjonsguiden — alt som trengs for å peke en checkout mot Gateway i stedet for å bygge en selv.
Den hostede siden med din logo, dine farger og din skrift, slik at du ser din egen checkout før du går live.
Mer å lese
Fungerer frittstående eller som whitelabel — ditt merke på checkout, våre spor nedenunder.
PoS bruker Gateways ordremodell i kassen, vIBAN gir banköverføringsordrene selvidentifiserende referanser, Chain gjør opp USDC-betalingene til EUR, Center er operatørkonsollen bak checkout, og Agents bruker samme ordremodell på betalinger initiert av programvare under menneskelig policy.
Alt ovenfor kjører i produksjonsdemoer vi kan vise deg – frittstående, whitelabel eller som én plattform. Fortell oss hva du bygger, så viser vi deg den korteste veien dit.
