Refunds against the order
A refund points at the order, not at a payment method. The drawer opens on 9F21-0716 with the amount preset to the full €49.00, a required reason, and an optional note that lands in exports and on the customer's receipt. Funds travel back over the original payment method automatically — card refunds to the card — typically in 1–3 business days.
Methods you switch, not build
Payment methods are toggles with providers behind them: cards with 3-D Secure, Apple Pay and Google Pay as one-tap buttons, SEPA bank transfer by vIBAN reference. Card routing and its 3-D Secure policy sit on the same screen, and you always settle in EUR.
Drop-in integration
Create an order, redirect to the hosted page, receive the result. Gateway carries the payment UI, the method logic, and the receipts. There is no checkout frontend for your team to build, patch, or keep current as methods change.
The order is the unit
Everything hangs off the order, not the payment method. Order 9F21-0716 carries its line items — a €38.50 brand identity sprint, €6.00 typeface licensing, €4.00 rush delivery — a €0.50 processing fee, and one total. However it gets paid, that reference is what you query, reconcile, and refund against.
Config that can't surprise a session
Method and branding changes apply to new checkout sessions — stated on the screen where you save them. A customer mid-payment never has the page change under their hands.
Cards, done properly
The card path is the boring part, handled: inline validation, 3-D Secure with strong customer authentication built into the flow under a readable routing policy, and per-sandbox test cards for integration runs. Adding a method never makes the card flow worse.
Apple Pay and Google Pay
They are buttons, not projects. Apple Pay and Google Pay render as one-tap sheets on the same page and pay with device tokens — the real card number never reaches the page — through the same order and the same receipt. Enabling them is a toggle on the methods screen.
Bank transfer by vIBAN
Pay-by-transfer carries a vIBAN reference, so an incoming SEPA payment identifies its order by construction. Turn it on for the customers who want an invoice they can pay from a bank, and reconciliation stays automatic.
Local methods where they matter
Beyond cards, Apple Pay, and Google Pay, the checkout carries the account-to-account and local methods a European buyer expects to see, presented by the customer's country rather than dumped in one long list.
Buy now, pay later
BNPL sits on the same method row as everything else — the customer splits the payment, the merchant is paid once, and the order reference does not change. One toggle, same receipt, same reconciliation.
Methods that read the customer
The page orders methods by what the customer is likely to use — country, language, device, and whether they have paid you before — so the relevant option is the first one, not the fourth.
Priced in their currency, settled in yours
Show the amount in the customer's currency with the conversion stated before they confirm, and settle to EUR regardless. The customer sees a familiar number; your ledger keeps one.
A checkout in their language
The hosted page localizes its labels, errors, and receipts. Nobody abandons a payment because the button was in the wrong language.
Saved cards and one-click
A returning customer pays with a stored card in one tap. The card is vaulted on our side and referenced by token, so your systems store a reference, never a PAN — and the second purchase is shorter than the first.
Subscriptions and recurring billing
Recurring charges run on a schedule you define — amount, interval, start and end — against a tokenized card. Each cycle produces its own order and its own receipt, so a subscription reconciles line by line like everything else.
Retries that recover revenue
A soft decline on a recurring charge is retried on a schedule rather than written off, and the customer is only told about it when it matters. Failed renewals stop being silent churn.
Network tokens and card updates
Stored cards are held as network tokens and follow the cardholder through reissues and expiries. The subscription that used to break when a card was replaced keeps charging.
An API and a developers surface
Orders are created by API with idempotency keys — a retried request returns the original result, never a second charge — and the developers section carries the keys and the docs. The checkout is hosted; the integration is a handful of endpoints, documented where the settings live.
Webhooks on the order lifecycle
Your backend hears about payments the moment they happen: signed webhook events on the order lifecycle — paid, failed, refunded — with signature verification on your side and replay protection on ours.
Mobile SDKs for iOS and Android
Native apps present the same checkout in-app rather than kicking the user into a browser. The SDK carries the method logic, the Apple Pay and Google Pay sheets, and 3-D Secure; the order and the receipt are the ones your backend already knows about.
Shopping-cart plugins connect an existing store to Gateway without a developer — install, paste the keys, take a test payment. The same orders land in the same back office as the API ones.
Embedded fields on your own page
When the payment has to happen inside your own layout, embed the payment fields directly: the inputs are hosted and PCI-scoped on our side, the page around them is entirely yours, and card data never touches your servers.
Single-use, multi-use, expiry
A link can close after one payment or keep collecting — the demo's workshop seat has taken 3 payments, the consultation hour 6. Links auto-expire after 30 days by default, and expired links say so instead of failing quietly.
Test mode
Integration runs happen against test sessions with the cards issued alongside your sandbox keys, before anything real moves. The flows are identical, so what passes in test is what ships.
Routing you can read
Card traffic follows a routing policy written in terms you recognise — card brand, issuing country, currency, amount — rather than a black box. You can see which route a payment took, from the same screen that shows the payment.
A second attempt before a lost sale
A soft decline is retried on an alternative route inside the same checkout session, before the customer sees a failure. Most recovered payments are ones the customer never knew were at risk.
Declines in plain language
Raw issuer codes are translated into reasons an operator can act on — expired card, insufficient funds, issuer risk — and grouped so a pattern across many payments is visible as a pattern.
3-D Secure as policy, not friction
Most payments pass on device and behavioural signals alone; a step-up challenge appears when the policy calls for it. You set the policy — always, risk-based, or exempt where the rules allow — and the hosted page carries the flow.
One line to reconcile
Checkout, receipt, and settlement carry the same order reference. Whoever matches 9F21-0716 finds one €49.00 entry — not a card record in one system and a bank-transfer record in another.
Settlement and payouts
Settlement is stated where you configure it: settle to RO49 •••• 0421, payout daily at 23:00. The number the accountant sees tomorrow is decided on a screen the merchant can read today.
A payout you can trace back
Every payout opens into the orders that funded it, with fees itemised. The bank line matches a list you can export, so month-end is a lookup rather than an investigation.
Partial refunds
The refund amount is editable up to the original charge — the drawer shows the maximum and treats anything less as a partial. Ten partial refunds against one order still reconcile against one reference.
Refund reasons on the record
Every refund carries a required reason and an optional note, and the note travels: it appears in exports and on the customer's receipt. Six months later, nobody has to remember why order 9F21-0716 was made whole.
Receipt delivery
Receipts are e-mailed to the customer and downloadable on the spot, and refund receipts follow the same path. The merchant never builds a receipt template.
Void before settlement
Cancelling before the day's batch releases the authorization hold and no money moves — no refund, no fee, nothing on the customer's statement to explain.
Risk controls on by default
Card payments run 3-D Secure under a routing policy you can read. Apple Pay and Google Pay payments carry the device's own authentication, and webhook events are signature-verified before they are trusted.
Rules you write in your own terms
Screening rules read like sentences — amount over X from country Y on a first-time card — and act on them: allow, challenge, or block. Lists of trusted and blocked cards, e-mails, and addresses sit behind the same screen.
Velocity and device signals
Repeated attempts from one card, one device, or one address are caught by rate rules rather than by a person noticing later. The signals are shown on the payment, not buried in a score.
Disputes with the evidence attached
A chargeback opens with the order behind it: authorization result, 3-D Secure outcome, receipt, delivery, refund history. Respond from that screen, and the evidence pack is assembled from the record rather than from memory.
Card data never reaches you
The page collecting card details is ours, PCI-scoped and hosted. Whether the customer pays on our domain, yours, or inside your app, your servers see a token and an order reference — never a card number.
Encrypted at rest, in the EU
Payment data is encrypted at rest and processed in the EU. For a European merchant, where the data lives is an answer, not a footnote.
Every action on the record
Refunds, method changes, branding changes, key rotations — each is written to an audit trail with the operator, the timestamp, and the reason. Privileged actions require a reason before they run.
Roles for the people who need them
Finance sees payouts, support sees orders and issues refunds, developers see keys and logs. Access is granted per role rather than by sharing one login.
A customers directory
Payers accumulate into a customers view — who paid, how often, by what method — so a repeat customer is a record, not a coincidence of matching e-mails in exports.
Search and CSV export
Find a payment by link or reference from the search box; export the current view to CSV when the books need it. The back office assumes an accountant will ask.
The numbers, by day and by method
Volume, approval rate, refunds, and method mix, over the period you choose. Enough to answer where the money went and which method is worth promoting — without exporting anything.
The operator view behind it
Gateway plugs into Protocore Center: the payment-links back office there shows every link with its settlement transfer attached and an open-in-Tracer link for the full trace. Your ops team sees through the checkout down to the ledger.
The demo checkout belongs to Arc Studio SRL: their name, their mark, their order. The footer can drop our name entirely, so the page reads as yours.