Book a revenue review
Developers

Higher approvals, a few lines away.

You create a payment session and read the result. Everything that lifts the approval rate — classifying declines, choosing a retry route, requesting SCA exemptions, refreshing network tokens — runs on our side, behind that one call. Your code stays a thin client, and a webhook tells you the moment a payment is recovered.

Read the docs How tokens work
One integration

Create a session, read an approval

The whole surface area is a payment session and the result that comes back. You never build retry logic, never script a 3-D Secure flow, never store a card. Start against the sandbox, point at the live keys when you are ready, and the same call gets smarter behind the scenes as we tune it.

  • One call, not a pipeline. Create the session, render the checkout, read approved or declined. That is the contract.
  • Retries and 3-D Secure handled for you. Soft-decline recovery and frictionless authentication happen server-side, not in your code.
  • You never touch raw card data. Details are tokenized at the network, so your servers stay outside PCI scope.
  • Sandbox first. Every decline reason and recovery path is reproducible in test before a single real payment.
What you build with

A small kit that does the heavy lifting

Three things to integrate against — the checkout, the token vault and the webhooks. The approval logic lives behind all three.

Drop-in checkout and SDKs

Render a hosted checkout or mount the components, on the web and in mobile apps. The SDKs handle the payment session and the 3-D Secure step, so your front end just collects intent and shows the outcome.

Web + mobileHosted or components

Network-token vault

Cards are tokenized at the network the first time they are used, and the token is kept current as cards expire or get reissued. You store the token reference, never the PAN, and returning shoppers stay approvable.

PCI out of scopeAuto-refresh

Webhooks for recovered payments

Your code reacts to a webhook when an authorization resolves. Listen for payment.approved, payment.recovered and payment.soft_declined to fulfil, reconcile and report — no polling required.

Signed eventsIdempotent
From keys to live

Four steps to a smarter checkout

Each step is reproducible in the sandbox before it touches real money, so going live is a switch, not a leap.

01

Get your keys

Sign in, create a sandbox project and copy the test keys. Live keys appear next to them the moment your account is verified.

Authenticate
02

Add the checkout

Drop in the hosted checkout or mount the SDK components, then create your first payment session from the server.

Integrate
03

Test in sandbox

Trigger soft declines, hard declines and 3-D Secure challenges on demand, and watch retries and tokens resolve them.

Reproduce
04

Go live

Swap test keys for live keys and point your webhooks at production. The same session call now recovers real payments.

Ship
Off your plate

The complicated parts run on our side

The logic that actually moves the approval rate is the logic you would least want to maintain. We run it behind the session call so your integration never grows a tangle of edge cases — and gets the benefit of every improvement we ship.

  • Decline classification. Each refusal is sorted into soft or hard before anything else happens, so genuine declines are left alone.
  • Retry routing. Recoverable declines are retried once, on the route and at the moment most likely to clear.
  • SCA exemptions. We request the right exemption so eligible payments skip the challenge and stay frictionless.
  • Token refresh. Network tokens are kept current as cards change, with no work on your side.
The integration in numbers

Small to add, quick to ship

~1 day
Time to first payment
From sandbox keys to a first approved test payment, for most teams.
6 SDKs
Languages and platforms
Server SDKs plus web and mobile clients, all against one API.
20+
Webhook events
From payment.approved to payment.recovered, signed and idempotent.
0 lines
Of retry logic to write
Recovery, routing and SCA strategy live server-side, not in your code.
For the engineer integrating

Three things you will want to confirm

Do I ever handle raw card data?

No. Card details are collected by the hosted checkout or the SDK components and tokenized at the network, so the PAN never reaches your servers. You store and reference a network token, which keeps your systems out of PCI scope.

Is there a sandbox?

Yes. Every project starts with sandbox keys, and you can trigger any outcome on demand — soft declines, hard declines, 3-D Secure challenges and successful recoveries. Test keys and live keys sit side by side, so promoting to production is a key swap.

Do I implement the retry logic myself?

No. Classifying declines, choosing a retry route and timing, requesting SCA exemptions and refreshing tokens all run server-side, behind the session call. Your code creates the session, reads the result and reacts to a webhook when a payment is recovered.

Ship the call. We will keep making it smarter.

Read the docs to integrate today, or book a revenue review and we will walk your team through the session model and the recovery that runs behind it.

Read the docs Book a revenue review