/// Method · Cards

Card payments, done properly.

Cards are the method nobody gets to skip, which is why the boring parts matter most: inline validation, 3-D Secure 2.0 under a policy you set rather than friction by default, a routing policy you can read, and a retry on an alternative route before a soft decline turns into a lost sale.

Visa·MC
And co-badged schemes
3-DS 2.0
SCA inside the flow
EUR
Settled to your account
0
Card numbers on your servers
/// How it runs

Card to bank line, four steps.

  1. [ 01 ]

    ENTER

    The customer types the card on our hosted page — inline validation, no card data reaching you.

  2. [ 02 ]

    AUTHENTICATE

    3-D Secure runs to policy: most payments pass on signals, a challenge appears only when required.

  3. [ 03 ]

    AUTHORIZE

    Funds are verified and held, and a soft decline is retried on an alternative route.

  4. [ 04 ]

    SETTLE

    The day's orders batch and pay out in EUR against the same order reference.

/// 01

What the customer sees

One card form on the same page as every other method, with the order beside it. Fields validate as they're typed, the scheme is detected from the number, and the pay button states the amount rather than the word 'Submit'. If the issuer wants a challenge, it happens inline — the customer never leaves the page they started on.

  • [ 01 ]Card form alongside wallets, USDC, and transfer — not a separate step
  • [ 02 ]Inline validation and scheme detection as the number is entered
  • [ 03 ]3-D Secure challenge inside the page, when policy calls for it
/// 02

What you receive

Euros, batched into the day's payout, against the order reference you created. Authorization and capture are handled for you; the receipt records the scheme, the last four digits, and the authentication result. That record is also your dispute evidence — one lookup answers a chargeback rather than a search across systems.

  • [ 01 ]One EUR payout line per settlement batch
  • [ 02 ]Scheme, last four, and 3-DS outcome on the record
  • [ 03 ]Refunds issued against the order, full or partial, back to the same card
/// 03

What it takes to switch on

Cards are on by default. What you configure is the policy around them: when 3-D Secure steps up, how routing prefers one path over another, and what happens to a soft decline. Test with your sandbox card first — the flows are identical, so what passes in test is what ships.

/// FAQ

Card payments — questions merchants ask.

  • Not meaningfully. The page collecting the card belongs to us and is PCI-scoped on our side; your servers receive a token and an order reference. That holds whether the page runs on our domain, yours, in your app, or as payment fields embedded in your own layout.

  • It's the authentication step that satisfies strong customer authentication under PSD2. Most payments pass on device and behavioural signals with no challenge shown. A step-up appears when the policy — which you set — calls for it, so the friction is a decision rather than a default.

  • A soft decline is retried on an alternative route inside the same session, before the customer sees a failure. A hard decline is reported back in language an operator can act on — expired card, insufficient funds, issuer risk — not as a raw issuer code.

  • Authorization holds the funds at purchase; settlement moves them. The day's orders close into a batch and pay out in EUR at the daily payout time set in your settings — one bank line you can open into the orders that funded it.

Take a payment on every one of them.

A sandbox merchant, API keys, and a checkout with all of these switched on — so you can run each method end to end before you commit to anything.

Request sandbox access