Embedded payments
Checkout that stays inside your product, with the provider work handled behind it.
We build payment acceptance into your product so the customer never leaves it. Provider integration, tokenized capture, webhook handling and the failure states that follow. The card licence and money-transmission permissions stay with your regulated partner. We build the layer that talks to them and keeps your data model correct.
Where it fits
The problem
Right now the customer hits a redirect to a third-party page with someone else's branding, and a share of them never come back. Your support team explains a screen you do not control. Refunds live in a provider dashboard, and your database only learns about them when someone checks manually.
What we build
We put the card fields in your page as a hosted field iframe, which keeps you inside PCI DSS 4.0 SAQ A scope. Tokens go to the provider, never through your servers. Webhooks land on an idempotent endpoint, write to your payment ledger, and drive the states your product shows.
How we engage
Senior engineers only, working in your repository and your review process. The payment ledger and the webhook workers run in your infrastructure, on your cloud account, under your keys. We document the provider quirks we hit, hand over the runbooks, and the code stays yours to run without us.
What we build
Six pieces of the payment path we build most often.
Hosted checkout fields
Card entry sits in your layout, styled with your tokens, while the sensitive fields live in the provider iframe. Your brand carries through the whole purchase. Before this, teams ship a redirect that breaks on mobile browsers and leaves the buyer wondering which company just charged them.
Tokenized capture
We wire single-use tokens for the first charge and provider-held card-on-file tokens for repeat billing, so no primary account number touches your logs or your database. The pain we usually find first is a debug log from an early integration sprint that quietly captured full card data for months.
Webhook handling
Providers retry, deliver out of order, and sometimes send the same event twice. We verify signatures, key every event by provider id, and make handlers idempotent so a replay changes nothing. The before-state is a duplicate shipment because two capture events arrived within the same second.
Failed payment states
Declines are not one state. We map issuer codes into groups your product can act on, retry the soft ones on a schedule, and route the ones needing a challenge back to the cardholder. Most teams arrive with a single failure screen that tells the buyer nothing and drops the sale.
Payouts and splits
When money has to reach several parties, we model the split on your own ledger first and then instruct the provider. Fees, reserves and payout timing all become queryable records. Teams often start with a monthly spreadsheet where someone reconciles seller balances by hand and nobody trusts the total.
Reconciliation and reporting
We ingest the provider settlement file each day and match it line by line against your ledger, then raise the breaks that need a human. Finance stops closing the month from four exports and a set of assumptions about which fees belong to which order. Breaks get an owner and an age.
Checkout, webhooks and settlement in one working path
The demo runs a card charge through hosted fields, replays a duplicate webhook, and shows the ledger holding steady.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
Provider-agnostic payment layer
Your product talks to our interface, and the provider adapter sits behind it. Adding a second acquirer for a new market becomes an adapter and a routing rule instead of a rewrite of checkout. That matters the first time a provider changes pricing or drops support for a country.
Honest about the licence
We are a software engineering vendor. We hold no acquiring licence and no money-transmission permission, and we say so in the first call. The regulated partner or your own entity carries that, and we design the integration around what their rulebook and your compliance team will accept.
Failure paths get built first
Payment code spends most of its life in the unhappy path. We write the timeout, the partial capture, the late refund and the disputed charge into the design before the happy path ships, because those are the tickets your support team will live with for years.
Questions
Who holds the licence for the money movement in our checkout?
Not us. The acquiring licence and the money-transmission permissions sit with a regulated partner or with your own entity if you hold one. We build the integration, the ledger and the reconciliation on top of that arrangement. We will read the partner rulebook with you and flag where a product decision needs their written sign-off.
Does putting checkout inside our app expand our PCI DSS scope?
It depends on how the card data is captured. With provider-hosted fields or an iframe, cardholder data never reaches your systems and you generally stay in PCI DSS 4.0 SAQ A territory. Collect the fields yourself and the scope grows considerably. Your acquirer and your QSA confirm the final scope, so we design toward the lighter option and document the data flow for them.
How do you handle SCA and 3-D Secure without wrecking conversion?
PSD2 strong customer authentication applies to most European card payments, with exemptions the issuer may or may not honour. We request exemptions where the rules allow, keep the challenge inside your flow rather than a bounced-out page, and treat a soft decline as a resumable state. Numbers depend on your mix of issuers and baskets, so we instrument it and read the data.
Can we switch payment providers later without rebuilding checkout?
That is the reason for the adapter boundary. Your product writes to one internal payment interface, and each provider gets an adapter behind it. A migration then means a new adapter, a routing rule and a period of dual running while you compare authorisation results. Stored card tokens are the hard part, because most providers require a formal token migration between them.
Part of Embedded Finance
The finance layer inside your product, built and run by the same engineers.
Financial features,
native to your product.
Tell us what you want to embed: payments, cards, lending, payouts. We'll build the integration, orchestration and ledger around your providers.