Cards & wallets
Card and wallet acceptance across markets behind one tokenized integration.
Shoppers in each market reach for a different card scheme or wallet. Oxagile Financial Services builds the acceptance layer behind that variety, one tokenized integration that routes card, Apple Pay, Google Pay and local scheme traffic, holds card data inside a PCI DSS 4.0 scope you can defend, and reports approvals per market.
Where it fits
The problem
A new market usually means another provider SDK, another set of webhooks, another checkout branch. Support teams re-key declined orders by hand. Nobody can say why approval rates differ between Poland and Brazil, because each provider reports declines differently and the numbers end up in separate spreadsheets.
What we build
We build the acceptance layer. A payment method registry per market, network tokens and provider tokens held in a vault, 3-D Secure 2 exemption logic mapped to PSD2 SCA, retry timing per decline code, and a checkout front end that surfaces the methods a shopper recognises. Approval data lands in one schema.
How we engage
Senior payment engineers join your team, work in your cloud account and your repositories, and write the runbooks with your on-call engineers. Code review happens in your pipeline. When the engagement closes, the acceptance layer is yours to run, with vault access, dashboards and provider contracts in your name.
What we build
Six pieces make up a card and wallet layer that survives the next market launch.
Card acceptance routing
Global schemes and domestic card networks sit behind one API, with routing rules per market, currency and card product. Teams that hard-code a provider per country ship a release for each new country. Here a market goes live by configuration, and the contract the checkout calls stays the same.
Tokenization and vault
Provider tokens and network tokens live in a vault your team controls, so a stored card keeps working when you add a second acquirer. Card data stays out of your application logs. That keeps the merchant assessment closer to SAQ A instead of pulling your whole platform into PCI DSS 4.0 scope.
3-D Secure 2 flows
Authentication runs through 3-D Secure 2 with exemption logic mapped to PSD2 SCA rules, so low-risk baskets pass without a challenge screen. Merchants who challenge each transaction watch mobile conversion drop. Risk signals go into the authentication request, and challenge rates get reviewed per issuer rather than in aggregate.
Approval rate tuning
Decline codes get normalized across providers, then retries follow timing rules per code instead of one fixed loop. Soft declines retry, hard declines stop. Finance teams who guess at lost revenue today get a per-issuer view of declines, and product teams see what a rule change did to approvals.
Provider failover
A second acquirer stays wired and warm, with health checks and a switch that moves traffic once authorization latency or error rates cross a threshold. Single-provider setups turn a provider incident into a checkout outage, and the support inbox fills up before anyone thinks to read a status page.
Checkout and wallets
The payment sheet lists what a market recognises, with Apple Pay and Google Pay surfaced where the device supports them. Saved cards render with issuer art and expiry warnings. Your team stops maintaining four checkout forks, because method availability comes from configuration rather than branches in front-end code.
One integration, many markets, tokens you keep
A card and wallet layer where adding a market is a configuration change and the token vault stays under your control.
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
Engineers who ship payment code
The people writing your acceptance layer have handled acquirer certification, decline taxonomies and PCI DSS 4.0 assessments before. Discovery gets shorter, and the design stays honest about how providers behave under load. Teams that staff this with generalists pay for the same learning curve twice, once in delay and once in rework.
Your cloud, your keys
Deployment happens in your accounts against your infrastructure as code, with vault access held by your security team. You hold the keys to your own token data, and the acceptance layer keeps running after the engagement ends because your team already operates it.
Approval data in one schema
Provider reports get normalized into one event schema, so approval rate, decline reason and challenge rate compare across markets. A question about which market declines most becomes a query and a shared dashboard, answered the same way by everyone who asks it.
Questions
Do we have to replace our current payment provider?
No. The acceptance layer sits above providers, so your current acquirer keeps taking traffic while a second one gets wired behind the same interface. Migration runs per market or per traffic share, with both paths reporting into one schema so you compare approval rates before moving volume. Rollback is a routing change.
How does this affect our PCI DSS scope?
Card data reaches the provider or the vault through hosted fields or a client-side token request, so your servers handle a token reference. That keeps the merchant assessment closer to SAQ A, though the exact scope depends on your integration pattern and your assessor. We document the data flow for the QSA review.
Can you improve our approval rates?
We measure them properly first. Decline codes get normalized per provider and issuer, retry timing gets mapped per code, and 3-D Secure 2 exemptions get applied where PSD2 SCA allows them. Changes ship behind flags with before and after reporting, so your team sees which rule moved approvals instead of trusting a vendor claim.
Who runs the system after the project ends?
Your team does. We work in your repositories and your cloud from the first sprint, pair with your on-call engineers, and write the runbooks and dashboards they will use. Handover covers provider credentials in your name, load test results and the decision log behind the routing rules, so later changes do not need us.
Delivered in the field
Regional payment orchestration for a D2C media platform
D2C OTT & media subscription platform
A D2C media platform expanding into MENA, LATAM, and Southeast Asia now owns a payment orchestration layer that routes every charge to the processor most likely to approve it. Payments moved out of the engineering backlog and into the hands of the business.
PSP-independent payment layer for a subscription platform
UK meal-kit subscription platform
A UK meal-kit subscription platform now owns a payment orchestration layer that treats every PSP as a plug-in behind one internal contract. We built that layer while moving millions of live subscriptions to a new provider with zero downtime.
Part of Payments
Acceptance, orchestration, and settlement, engineered to stay up and keep approvals high.
Ready to make payments
a product you control?
Tell us where money gets stuck: routing, approvals, reconciliation, a PSP you've outgrown. We'll come back with the build, not a brochure.