Payment orchestration on one first-party platform.
BazPay is a first-party payment orchestration layer for EU low-risk merchants. Routing, risk, retries and reconciliation run inside the same platform that holds the acquiring licence, the vault and the ledger. There is no reseller stack between the decision and the settlement.
Cards, wallets, EU local payment methods, open banking and payouts share one REST API, one signed webhook stream and one interchange++ statement. You wire it once — added rails ride the same shape.
Why merchants pick a first-party payment orchestration layer
Third-party orchestrators exist to compensate for fragmented rails. When the rails already live in one platform, orchestration stops being a bolt-on and starts being a design property.
-
One layer, not a stack of PSPs
The rails, the risk engine, the vault and the ledger belong to the same platform. You are not stitching a third-party orchestrator on top of a chain of resellers — the decisioning is where the money moves.
-
Routing decisions read from one rule set
The rule that picks the rail, the rule that claims the SCA exemption and the rule that authorises the retry all live in the same engine. Editing one does not desynchronise the others.
-
One reconciled ledger
Every authorisation, capture, refund, dispute and payout closes into the same statement. No cross-provider ledger stitching, no monthly month-end guessing about which line belongs to which PSP.
-
One integration for the full lifecycle
A single REST endpoint covers charge, capture, refund, dispute and payout. Signed webhooks confirm every state change. You wire it once and every added rail rides the same shape.
The rails under one decisioning surface
Four rail families share the charge object. The routing engine picks between them. The reconciliation ledger collapses them back into a single statement.
-
Card rails
Direct card acquiring
Visa, Mastercard, Maestro and Cartes Bancaires clear on our own EU acquiring licence. One MID, one settlement balance, one reporting surface.
- Visa
- Mastercard
- Maestro
- CB
-
Wallets
Tokenised device wallets
Wallets ride the same acquiring rail as raw card charges. Network tokens keep saved cards live through reissue.
- Apple Pay
- Google Pay
-
Local methods
EU APMs alongside cards
APMs sit behind the same charge object. A flag on the request picks the method — the response shape never changes.
- iDEAL
- BLIK
- Bancontact
- EPS
- Przelewy24
-
Bank rails
Open banking and payouts
Bank-to-bank payments and merchant payouts run on the same platform, so refunds and disbursements share the ledger.
- SEPA
- SEPA Instant
- Push-to-card
Rail-specific depth: card and APM processing, open banking, payouts and recurring billing.
Eight stages under one charge object
Intake, score, authenticate, route, capture, retry, reconcile, payout. Every stage change is visible in the dashboard and fires a signed webhook.
-
Intake
The charge request lands on a single endpoint. Payment method, currency, ceiling and metadata are declared upfront.
-
Score
Fraud rules and risk signals resolve into one verdict: allow, step up, review or block, before the acquirer sees the request.
-
Authenticate
3-D Secure 2.2 fires only when the rule earns it. Exemption logic claims TRA, low-value and MIT paths where PSD2 allows.
-
Route
Rule-based routing selects the acquiring connection or APM provider best matched to the BIN, currency and merchant profile.
-
Capture
Immediate or delayed capture. Partial captures and partial refunds post cleanly against the original authorisation.
-
Retry
Soft declines trigger an idempotent retry policy — refresh a network token, wait a scheme window or re-route the request.
-
Reconcile
Every event lands in the same ledger with interchange++ line detail. One statement covers cards, APMs, refunds and payouts.
-
Payout
Merchant settlement into an EU IBAN on scheme cycle. SEPA Instant, SWIFT or push-to-card options on approved corridors.
Bolt-on orchestrator vs first-party platform
A bolt-on orchestrator adds a hop between the checkout and the acquirer, holds a copy of your tokens and reconciles across systems it does not control. When the platform is the acquirer, the vault and the ledger, that whole layer collapses inside.
| Dimension | BazPay (first-party) | Bolt-on orchestrator stack |
|---|---|---|
| Vendor count | One direct platform | PSP + orchestrator + vault + ledger |
| Contract chain | Direct acquirer | Reseller stack under aggregator |
| Rule surface | Routing + risk + retries in one engine | Rules split across systems |
| Vault portability | Native, first-party | Bolt-on token proxy |
| Reconciliation | One statement | Cross-provider stitching |
| Latency | Sub-second, single hop | Extra hop per orchestrated call |
| Support surface | One contract for issues | Ticket bounced between vendors |
Underlying acquirer relationship on merchant acquiring. Rates and statement structure on pricing.
Features inside the orchestration layer
Every capability below ships on the standard integration. Turn features on with a request flag or a dashboard toggle. No enterprise-tier gate on the primitives.
-
Rule-based routing
Route by scheme, BIN, currency, ticket size or merchant subaccount. Publish rule changes from the dashboard with no engineering release.
-
Retry policies
Per-reason retry rules — network-token refresh on 54, connection re-route on 05, dunning schedule on 51 — all keyed to the original charge.
-
Exemption engine
PSD2 low-value, TRA, trusted-beneficiary and merchant-initiated exemptions applied automatically to reduce challenge frequency.
-
Gateway-side vault
Store credentials once and reuse them across renewals, upgrades, one-clicks and cross-rail conversions without exposing PAN.
-
Signed webhooks
HMAC-signed, replay-protected events for every state change — charge, capture, refund, dispute, payout — feed your systems asynchronously.
-
Idempotent API
Retry-safe create requests keyed to your header. A network blip never becomes a double charge across the orchestration layer.
-
Interchange++ reporting
Scheme fees, interchange and margin split on every settled transaction. One statement, one export, one reconciliation.
-
Real-time decline data
Reason codes stream to the dashboard within seconds so ops can act on route quality before the daily report lands.
One API, one charge object, every rail
The endpoint that authorises a card charge also authorises an APM, an open-banking pull or a payout. The payment_method flag picks the rail and the routing engine picks the connection. The response shape is identical, so integration code stays lean.
POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
{
"amount": 4990,
"currency": "EUR",
"payment_method": "auto",
"routing": {
"preferences": ["ideal_if_nl", "card"],
"on_soft_decline": "retry_alt_route"
},
"three_d_secure": "required_if_needed",
"descriptor": "ACME EU LTD",
"metadata": { "order_id": "ORD-10842" }
}The response returns the canonical charge with the chosen route, the rule ID that picked it, the SCA outcome and the interchange bucket. Read the complete schema in the API reference and the retry catalogue in the developer docs.
Where a first-party orchestration layer earns its keep
Four merchant profiles tend to benefit most from consolidating routing, risk and reporting into one platform. The default rules already reflect them.
-
Multi-country e-commerce
One orchestration layer for EU storefronts on Shopware, Magento 2, WooCommerce or PrestaShop — cards, wallets and local methods without stitching regional PSPs.
-
Subscription software
Card-on-file renewals with MIT exemptions, dunning-aware retries and refund automation on the same platform that boarded the merchant.
-
Professional services
Higher-ticket B2B invoicing with named-payer trust lists, enforced 3-D Secure 2 above a ceiling and matching payouts to suppliers.
-
Digital publishers
Membership renewals, single-issue purchases and paywall unlocks orchestrated through one API with per-SKU reporting.
Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM.
Security and compliance signals
Consolidating the layer inside the acquirer also consolidates the compliance posture. The orchestration surface runs inside a PCI DSS Level 1 environment audited each year; hosted fields keep your annual return at merchant SAQ A; PSD2 SCA and exemption logic fire on every card charge.
- PCI DSS Level 1
- Annual assessment on the acquiring and gateway environment
- Merchant SAQ A
- Hosted fields and gateway vault keep card data out of your stack
- PSD2 SCA
- 3-D Secure 2.2 with exemption engine on every card charge
- GDPR
- EU data residency; DPA available on request
- SEPA / SEPA Instant
- Direct participation for merchant payouts in supported corridors
Questions payments teams ask first
What is payment orchestration, and where does BazPay fit?
Payment orchestration is the decisioning layer that decides which rail a charge takes, when to retry it, when to challenge it and how to reconcile it. Most orchestrators route across third-party PSPs. BazPay is different — it is a first-party payment orchestration layer, meaning routing, risk, retries and reconciliation all run inside the same platform that also holds the acquiring licence and the ledger.
Is BazPay a marketplace of third-party PSPs?
No. BazPay is a direct EU acquirer for the card schemes it supports and integrates named partner processors for selected local payment methods that clear through them. There is no reseller chain and no third-party PSP layer between merchants and settlement — the platform is single-vendor by design.
How does the routing engine choose a rail?
Routing rules read from the charge object — payment method flag, BIN range, currency, ticket size, merchant subaccount and any custom metadata you attach. Rules resolve deterministically. The chosen route and the rule ID that selected it are written to the charge for full audit.
Can I change rules without an engineering release?
Yes. Routing, retry and risk rules are edited from the dashboard and take effect on the next order. Every rule change is version-logged, so you can revert without redeploying and see the effect in real-time analytics within minutes.
How are retries handled?
Each decline reason has a defined retry policy. Expired-card returns trigger a network-token refresh. Do-not-honour codes trigger a re-route to a second connection. Insufficient-funds codes schedule a dunning retry. Every retry is bound to the original charge with an idempotency key, so double-charges are structurally impossible.
What does the orchestration layer cover beyond authorisation?
Capture, refund, dispute defence, payout, recurring billing and the reconciliation ledger — all on the same endpoint shape and the same signed webhook stream. Cross-rail flows (card refund into an APM balance, for example) are first-class rather than manual.
Which merchants can use BazPay orchestration?
BazPay boards EU low-risk merchants: e-commerce sellers, subscription software firms, professional-services businesses and digital publishers. BazPay does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM businesses.
How does this differ from a bolt-on orchestrator on top of an existing PSP?
A bolt-on orchestrator adds a hop between your checkout and the acquirer, holds a copy of your tokens and reconciles across systems it does not control. BazPay is the acquirer, the vault and the reporting surface — the layer that would normally be bolted on is inside the platform, so latency, support and reconciliation all collapse to one place.
Consolidate your payments layer
Share your current rail count and volumes, and we will scope which retry, routing and exemption rules are worth turning on first. Sandbox keys are self-service — see also anti-fraud controls and the API reference. Related: the underlying network payment gateway, merchant acquiring and how BazPay compares as a payment provider.