SWIFT payment processing for merchant payouts on approved corridors.
BazPay handles SWIFT payments for outbound merchant payouts on corridors reviewed and enabled at boarding. The wires run on standard SWIFT messaging, land in the same dashboard as your card and SEPA Instant settlements, and fire the same signed webhook stream — no separate correspondent-bank relationship to open.
Built for merchants across the EU, UK, Australia, Canada and New Zealand who pay beneficiaries outside SEPA Instant reach — subsidiaries, contractors or royalty recipients in approved corridors. Local-currency flows stay on SEPA Instant by default; SWIFT is used only where the corridor requires it.
Why SWIFT payouts belong inside your acquiring platform
Running SWIFT wires on a stand-alone bank portal creates a second operational surface for your finance team and a second reconciliation flow. Four properties keep the SWIFT payment inside the same platform as the rest of your payment traffic.
-
SWIFT alongside SEPA Instant on one contract
SWIFT payouts run through the same BazPay contract that handles your card acquiring and SEPA Instant settlement. One dashboard, one signed event stream, one operational surface — no separate correspondent-bank relationship to open before you can pay a beneficiary outside SEPA Instant reach.
-
Approved-corridor discipline
Every SWIFT corridor is reviewed at boarding. The corridors your business needs are enabled explicitly, so wires land in expected currencies and jurisdictions instead of getting rejected mid-flight.
-
Signed events on every state change
Payout initiated, accepted, in transit, credited and (where returned) failed — every state fires an HMAC-signed webhook on the same signature scheme as your card and SEPA Instant events.
-
Reconciled inside the same finance stack
SWIFT payout lines land in the same interchange++ statement view as card settlement and instant payouts, so your finance team reconciles cross-border wires against the same ledger schema as everything else.
SWIFT alongside SEPA, SEPA Instant and card push
Four rail families cover outbound merchant payouts. The platform picks the rail per beneficiary — SWIFT is reserved for corridors SEPA Instant does not reach.
-
Payout rails
SWIFT for approved outbound corridors
Cross-border merchant payouts on the SWIFT network for corridors reviewed and enabled at boarding. Useful when a beneficiary sits outside SEPA Instant reach or in a currency SEPA Instant does not carry — the wire itself moves on standard SWIFT messaging.
- Outbound wires
- Approved per-corridor
- MT / ISO 20022
-
Instant rails
SEPA and SEPA Instant for dollar flows
For EUR payouts inside SEPA Instant, standard SCT settles same or next business day; SEPA Instant delivers in seconds where both banks participate. SWIFT is reserved for out-of-scope corridors.
- instant CT
- SEPA Instant
-
Card push
Card push where enabled
Push-to-card payouts land instantly on eligible card programmes for approved corridors — a useful alternative to SWIFT when the beneficiary holds a card in scope.
- Push-to-card
-
Reporting
One reconciliation surface
Whether a payout leaves via SWIFT, SEPA Instant or card push, the settlement event lands on the same signed-webhook stream and the same interchange++ statement view.
- Signed events
- CSV export
Instant-rail depth on SEPA and SEPA Instant. Broader payout mechanics on payouts. The SEPA Instant-plus-adjacent processing view on Single Euro Payments Area processing.
How a SWIFT payment moves through the platform
Six stages describe the path from a settled charge to a beneficiary credit. Every stage change fires a signed event on the same webhook stream as your card and SEPA Instant events.
-
Balance
Card, wallet, APM and SEPA Instant settlements accumulate into your EUR balance on your named merchant identifier.
-
Instruct
Instruct a payout by API or dashboard. Pick the corridor and the rail; the platform validates against your approved list before it moves.
-
Route
SEPA Instant corridors go via SEPA or SEPA Instant. Non-SEPA Instant approved corridors route via SWIFT payment processing on standard messaging.
-
Track
SWIFT payouts carry a reference the beneficiary bank can quote. In-transit status is surfaced in the dashboard and via signed webhook.
-
Credit
The beneficiary bank credits the account. A signed payout.settled event fires to your integration with the value date and rail.
-
Reconcile
Payout lines land on the same interchange++ statement view as card settlement, keyed to the source charges for finance reconciliation.
SWIFT inside BazPay vs a stand-alone bank wire
Two credible options exist for cross-border payouts: run wires from your own bank's portal, or run them inside the payment platform that already handles the rest of your traffic. The comparison below shows where each approach shows its cost.
| Dimension | BazPay (integrated) | Stand-alone bank wire |
|---|---|---|
| Contract | Bundled with BazPay acquiring | Separate correspondent-bank relationship |
| Corridor scope | Approved per merchant, per corridor | Broad, merchant-managed |
| Event stream | Signed webhook per state change | Bank portal or MT reports |
| Reconciliation | Same statement view as cards + SEPA Instant | Separate bank statement to reconcile |
| Idempotency | Idempotency key on create | Manual retry with reference tracking |
| Fallback rails | SEPA + SEPA Instant + card push | SWIFT only |
Rate structure on the pricing page. Boarding path on merchant acquiring; ongoing service envelope on gateway services.
Features engineered into payment SWIFT flows
Every capability below ships on the standard integration. Corridor approvals and beneficiary controls stay dashboard-configurable — no premium tier gates the wire tracking or reconciliation view.
-
SWIFT payouts on approved corridors
Outbound wires enabled per corridor at boarding. Corridors outside your approved list are rejected before the wire moves.
-
SEPA + SEPA Instant alongside
Local-currency flows stay on instant rails by default; SWIFT is used only when the corridor requires it.
-
Signed payout webhooks
HMAC-signed events for initiated, in-transit, settled and returned states — one signature scheme across every payout rail.
-
Payout tracking references
Each SWIFT payout carries a reference the beneficiary bank can quote, surfaced in the dashboard and the webhook payload.
-
Idempotent payout API
Retry-safe payout create requests keyed to your idempotency header — a network blip never sends the wire twice.
-
Interchange++ + payout reporting
Card settlement, SEPA Instant and SWIFT payouts appear in the same statement view for finance-team reconciliation.
-
Real-time payout data
Payout status, rail chosen and reference visible within seconds — push the stream into your existing observability stack.
-
Named onboarding review
A named integration engineer walks corridor approvals, KYC on beneficiary categories and payout controls before live keys are issued.
Instruct a SWIFT payout through the same REST API
One versioned REST endpoint creates a payout. The rail field either picks
SWIFT explicitly or lets the platform choose the correct rail per corridor. Idempotency
keys make the create request retry-safe end to end.
POST /v1/payouts
Idempotency-Key: 8f1c-2b3a-9e4d
BazPay-Version: 2026-04-01
{
"amount": 5450000,
"currency": "EUR",
"beneficiary": "ben_02H9K",
"rail": "swift",
"reference": "PAY-Q3-CONTRACTOR",
"metadata": { "quarter": "2026-Q3" }
}The response returns a canonical payout object with the chosen rail, the tracking reference and the expected value date range. Full schema in the API reference; handler samples in the developer docs.
Where merchants use SWIFT payouts alongside SEPA Instant
Four common patterns. Every one keeps EUR flows on SEPA Instant by default and reserves SWIFT for beneficiaries whose corridor SEPA Instant does not carry.
-
Multi-country e-commerce
DTC brands that pay non-SEPA Instant suppliers or subsidiaries on approved corridors while their regional book settles via SEPA Instant.
-
Subscription software
SaaS teams settling to shareholders, contractors or subsidiaries in currencies SEPA Instant does not carry, on corridors approved at boarding.
-
Professional services
Consultancies paying international contractors within the merchant's approved corridor list, alongside SEPA Instant to their regional workforce.
-
Digital publishers
Publishers paying royalty beneficiaries whose bank accounts sit outside SEPA Instant reach, tracked and reconciled inside the same dashboard as instant payouts.
Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a merchant of record and does not act as a marketplace of third-party PSPs.
Security, sanctions and AML posture
Cross-border payouts carry a compliance load that SEPA Instant-inside payouts do not. Corridors and beneficiary categories are reviewed at boarding; instructions to corridors outside the approved list are rejected before the wire moves. The card and gateway environment around the payout flow runs inside a PCI DSS Level 1 assessment renewed each year.
- 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 for merchant data; DPA available on request
- AML/KYC
- Merchant and beneficiary categories reviewed per corridor
Questions finance teams ask about SWIFT payment processing
What is SWIFT payment processing, and how does BazPay use it?
SWIFT is the international bank messaging network used to move money across corridors that fall outside domestic and regional schemes such as SEPA Instant. BazPay uses SWIFT for outbound merchant payouts on corridors reviewed and enabled at boarding. It is not an inbound acceptance rail — inbound card and APM traffic runs through BazPay's card acquiring and open-banking flows.
Which corridors and currencies does the SWIFT payment option support?
SWIFT payouts are enabled per corridor at boarding rather than blanket-on. The corridors and currencies available depend on your merchant profile, beneficiary categories and the compliance review completed during onboarding. If a corridor is not on your approved list, a payout instruction to that corridor is rejected before the wire moves — this is intentional to keep AML and sanctions posture tight.
How fast is a SWIFT payment compared with SEPA Instant?
For dollar flows inside SEPA, SEPA Instant delivers funds within seconds where both banks participate, and standard SEPA Instant settles same or next business day. SWIFT wires typically take longer to reach the beneficiary because they cross multiple correspondent banks and time zones; the exact value date depends on the corridor, the beneficiary bank and the cut-off times involved. BazPay stamps the value date on the signed payout.settled event when the beneficiary bank credits the account.
How is a SWIFT payment tracked once it leaves BazPay?
Every SWIFT payout carries a reference the beneficiary bank can quote — the same reference is surfaced in the dashboard and included in the signed webhook payload. In-transit, credited and (where applicable) returned states each fire their own event, so your finance stack sees the wire's progress without polling a separate bank portal.
What differentiates payment SWIFT processing here from a stand-alone bank wire?
A stand-alone bank wire runs on your own bank's portal and lands in a bank statement your team reconciles separately. BazPay's SWIFT payouts run inside the same platform as your card acquiring and SEPA Instant settlements, feed the same signed event stream and appear on the same interchange++ statement view — reducing the reconciliation surface and keeping cross-border payouts inside the same operational picture as the rest of your payment traffic.
Is BazPay a correspondent bank or a SWIFT member?
BazPay is a regional payment gateway and acquirer, not a correspondent bank. SWIFT payouts are executed through relationships that are reviewed at merchant boarding — the platform surface (API, dashboard, webhooks, reconciliation) is what your team touches. The specific banking partner arrangement is not disclosed at the marketing-page level and is discussed during onboarding.
Which merchant categories are eligible for SWIFT payouts?
Merchants across the EU, UK, Australia, Canada and New Zealand on the BazPay platform: e-commerce sellers, subscription software firms, professional-services businesses and digital publishers. Corridor approval is scoped to the merchant's business model and the beneficiary categories they need to pay. Adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM merchants are outside the underwriting policy and cannot use the payout flow.
Can I schedule SWIFT payouts and combine them with instant payouts?
Yes. Payout schedules and instructions are configured in the dashboard. A schedule can mix rails — SEPA Instant for EUR beneficiaries in-scope, SEPA Instant on eligible corridors and SWIFT for approved out-of-scope corridors — and the platform selects the correct rail per beneficiary automatically.
Scope your SWIFT corridors alongside instant payouts
Share the corridors and beneficiary categories your merchant business needs. A named engineer will confirm boarding fit and map the approved-corridor list inside one working day. See also Single Euro Payments Area processing and gateway services.