Transaction processing — every payment, one lifecycle.
BazPay handles card, wallet, local payment method and SEPA payment transactions on one REST API. Every online payment transaction resolves to a single canonical charge object, visible in the dashboard within seconds and confirmed by a signed webhook.
Built for EU, UK and Commonwealth e-commerce sellers, subscription software firms and professional-services companies. Idempotent writes, replay-protected events and high-volume routing keep the platform predictable under promo-day spikes and steady renewal traffic alike.
Why one lifecycle beats one integration per method
Four things stay true whether your book is small-ticket subscriptions or higher-value invoices. They are the reasons product, engineering and finance teams stop stitching per-rail systems together.
-
One transaction object, every rail
Cards, device wallets, local payment methods and SEPA Instant account-to-account all resolve to the same canonical charge object. Your code reads payment transaction data as one shape, not five.
-
Real-time visibility
Approvals, declines, exemptions, refunds and disputes appear in the payment transaction dashboard within seconds of the network response — no batch delay before your team can act.
-
High-volume behaviour built in
Idempotent create requests, back-pressure-aware webhook retries and horizontal capacity make the platform predictable at spike load, not just at steady state.
-
Ledger-grade reconciliation
Every processed transaction ties back to a single transaction ID from checkout through settlement, refund and chargeback — one primary key across the whole lifecycle.
Which payment transactions the platform processes
Four rail families run through one connection. Turn any of them on from the dashboard — no new contract per rail and no separate integration per method.
-
Cards
Card transaction processing
Visa, Mastercard, Cartes Bancaires and eftpos authorise on our own regional acquiring licence. Each online payment transaction posts against a named MID with the authentication result bound to it for issuer scoring.
- Visa
- Mastercard
- Cartes Bancaires
- eftpos
-
Wallets
Mobile payment transactions
Apple Pay and Google Pay ride the card rail with a wallet-supplied network token — no PAN in the request, and the native SDKs surface the same charge object as the web integration.
- Apple Pay
- Google Pay
-
Local methods
Local payment methods
Local schemes clear through the same platform and reconcile into the same settlement balance as card volume — one processing surface, not one per method.
- iDEAL
- Bancontact
- BLIK
- Pay by bank
- PayTo
- Interac
-
Bank rails
Account-to-account transactions
SEPA and SEPA Instant for local-currency pulls and payouts. Bank transaction processing runs bank-side, so no card data enters the flow at all.
- SEPA
- SEPA Instant
- Open banking
Payment-method depth on card and APM processing. Bank rails on open banking. Direct acquiring on merchant acquiring. Sibling pages: processing online payment, payment processing software and gateway services.
The life of one payment transaction
Six stages sit between the checkout button and the settled dollar on your bank account. Each stage is visible in the dashboard and each stage change fires a signed webhook keyed to the same charge ID.
-
Initiate
The checkout script or mobile SDK creates a payment intent, gathers device signals and issues a hosted-fields collection.
-
Score
The inline fraud engine grades the request against your rule set. Clean orders skip the extra step.
-
Authenticate
3-D Secure 2.2 runs only when the rules earn it; PSD2 exemption logic claims the rest for a frictionless path.
-
Authorise
The transaction posts to the network with authentication result and CAVV bound to it. The issuer response returns in real time.
-
Capture
Capture at once or later. Partial captures and partial refunds both post cleanly against the same charge ID.
-
Settle
Funds reconcile per scheme cycle and land in your local settlement account with interchange++ line detail on every row.
Transaction states you will see in the dashboard and the API
Eight machine-readable states cover the full charge lifecycle. Every state has a documented transition, a webhook and a place in the payment transaction dashboard — nothing about a charge is hidden from your engineering or ops team.
| State | Meaning | Notes |
|---|---|---|
| requires_action | Awaiting 3-D Secure challenge or shopper action | next_action returned |
| processing | Sent to the network, awaiting response | authorization pending |
| authorized | Approved, waiting for capture | capture window open |
| captured | Funds committed against the shopper | will settle on cycle |
| settled | Reconciled into your local settlement account balance | interchange++ line |
| refunded | Full or partial refund posted | refund object linked |
| failed | Declined by issuer, network or fraud rule | reason_code returned |
| disputed | Chargeback opened by issuer | evidence packet slot |
Live view lives in real-time analytics. Rule and scoring detail lives in payment fraud prevention.
Features engineered into the processing tier
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.
-
One canonical charge object
Every rail returns the same shape. Consumers of the API read authorisation, capture, refund and dispute events off one schema.
-
Idempotency keys
Every write accepts an Idempotency-Key header. Retry a create call on any network error without risking a duplicate charge.
-
Signed webhooks
HMAC-signed events for every state change, with a timestamp header for replay protection and monotonic event IDs.
-
Payment transaction dashboard
Filter live transactions by status, rail, BIN country, exemption reason or rule ID. Every row deep-links to its full audit trail.
-
Real-time analytics
Approval rate, decline mix and settlement latency visible within seconds — see what a rule change did before the next scheme cycle.
-
High-volume routing
BIN-aware routing and back-pressure-aware retries hold approval quality steady when your traffic spikes 5× on a promo day.
-
Interchange++ reporting
Every settled transaction breaks out interchange, scheme fees and processor margin — finance reconciles from the source, not a blended rate.
-
Chargeback pipeline
Scheme dispute events fire as signed webhooks with the 3-D Secure proof, the signals that scored the order and an evidence template pre-assembled.
Idempotent writes for financial transaction processing
Every write endpoint accepts an Idempotency-Key header. Send the same key
twice and the second call returns the first response byte for byte, so a network blip
during payment transaction processing never becomes a duplicate charge. Reads are safe
to retry without a key.
POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
{
"amount": 4990,
"currency": "EUR",
"payment_method": "card",
"capture": "auto",
"three_d_secure": "required_if_needed",
"descriptor": "ACME EU LTD",
"metadata": { "order_id": "ORD-10842" }
}The response returns the canonical charge object with the authorisation code, the state and the exemption applied. Full schema in the API reference; handler samples in the developer docs.
Where transaction processing earns its keep
The default configuration already reflects these four merchant profiles. Turn on the ones you need and tune the processing behaviour against your own traffic.
-
Multi-country e-commerce
Local card and APM acceptance across our markets on one integration. Peak-day promo traffic runs on the same processing path as steady-state.
-
Subscription software
Network-tokenised card-on-file, MIT exemptions on renewals and dunning-aware retries — millions of low-ticket transactions on one dashboard.
-
Professional services
Higher-ticket B2B invoicing with named-payer trust lists, enforced 3-D Secure 2 over your ceiling and clean per-invoice reconciliation.
-
Digital publishers
Membership renewals, single-issue purchases and paywall unlocks tracked per SKU with dispute events wired into your ledger.
Out of scope for BazPay: adult, gambling, cannabis, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a marketplace of third-party PSPs.
BazPay processing vs a per-rail integration stack
Building against a different vendor for every rail multiplies the work an engineering team does to reconcile one merchant. The comparison below explains why a single transaction lifecycle collapses that work.
| Dimension | BazPay (one lifecycle) | Per-rail vendors |
|---|---|---|
| Object model | One canonical charge object per rail | Different shapes per gateway |
| Idempotency | Required on writes, retry-safe by design | Best-effort or absent |
| Webhook contract | Signed HMAC, replay-protected, versioned | Unsigned or per-vendor formats |
| Dashboard latency | Sub-second on state change | Batch or delayed refresh |
| Reporting | Interchange++ line detail | Blended-rate summary |
| Peak-load behaviour | Back-pressure-aware retries | Undocumented drop behaviour |
Rate structure on the pricing page. Buyer's evaluation on payment processors. Bundled packaging on payments solutions.
Security and compliance signals for every processed transaction
The processing environment runs inside a PCI DSS Level 1 assessment renewed each year. Hosted fields, network tokens and gateway-side vaulting keep your annual return at merchant SAQ A. Authentication runs on every card charge with exemption logic where the rules allow.
- 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
- Authentication
- 3-D Secure 2.2 with automatic exemption logic on every card charge
- GDPR
- In-region data residency; DPA on request
- SEPA / SEPA Instant
- Direct participation for merchant payouts in supported corridors
Questions merchants ask about transaction processing
What does BazPay's transaction processing actually cover?
The platform takes a payment transaction from the moment a shopper submits at checkout, runs fraud scoring and 3-D Secure 2.2 authentication where the rules require it, posts to the relevant network, captures and settles the funds, then makes every state change available in the dashboard, the API and a signed webhook. Card, wallet, local payment method and instant rails share the same lifecycle.
How does the platform handle high volume transaction processing?
Three things carry high volume through the platform: idempotent create requests, back-pressure-aware webhook retries and per-BIN routing that keeps approval quality steady when traffic spikes. Merchants running promo days or subscription renewal windows see the same latency and error rate at peak as at steady state, because the processing tier scales horizontally under a single account.
Is there a payment transaction dashboard for ops teams?
Yes. The dashboard lists every transaction in near real time with status, rail, amount, MID, exemption reason and any rule IDs that fired. Filters cover status, rail, BIN country, order metadata and time range. Every row deep-links to the full audit trail — authorisation response, 3-D Secure proof, refund history and dispute events for that charge ID.
How is a payment transaction different from a settlement line?
A payment transaction is a single authorisation and capture against a shopper's payment method. A settlement line is the reconciled entry that arrives in your local settlement account once the scheme cycle closes. The BazPay API keeps them linked: every settlement line references the charge IDs that composed it, so your ledger closes against the source, not against a batch.
Does BazPay support electronic and digital transaction processing beyond cards?
Yes. The platform runs card acceptance alongside local payment methods, SEPA and SEPA Instant for account-to-account transactions, and open-banking flows. Every method produces the same charge object and the same webhook envelope — digital transaction processing and card processing are one integration, not two.
How reliable are the webhooks that drive downstream systems?
Every event carries an HMAC-SHA256 signature over the raw body, a timestamp header to prevent replay, and a monotonic event ID for ordering. Delivery retries follow an exponential schedule; a receiving service that returns a 5xx or times out will see the same event again with the same idempotency-safe body until it acknowledges.
What happens when the network is slow or an issuer times out?
The processing tier applies a per-BIN timeout and falls back to a retry path when the outbound network is degraded. Merchants see a normalised reason on the charge object and, where the retry succeeds, an approval that would otherwise have been logged as a soft decline. Every retry is recorded on the transaction for audit.
Which merchant profiles is this suitable for?
Merchants across the EU, UK, Australia, Canada and New Zealand: 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 merchants, and it is not a marketplace of third-party PSPs.
Post your first payment transaction today
Open a sandbox account and post a test charge in the same hour. Prefer a walkthrough? A payments specialist can map your rails, your payment fraud prevention rules and your payouts corridor with you, and connect the platform to the wider network payment gateway.