SEPA-area · pay-in & pay-out

SEPA payment system on one API — SCT, SCT Inst and SEPA Direct Debit behind one contract.

Every SEPA flavour through one unified API: instant credit transfers when the receiving bank supports them, consumer and B2B Direct Debit with mandate handling done for you, mass payouts in batches — and one reconciliation feed across pay-in and pay-out.

Book a SEPA review Read the API docs
SCT · SCT Inst · SDD
every SEPA flavour on one API
10s
SCT Inst settlement when supported
EU 27 + EEA
SEPA-area reach via licensed partners
1 ledger
across SEPA pay-in and pay-out

Catalogue

The four SEPA flavours behind the sepa payment method

Four SEPA flavours cover the vast majority of EU euro payments. Each is exposed through the same authorise endpoint with a different payload field.

  1. SCT

    SEPA Credit Transfer

    Single-leg euro credit transfers across the SEPA area. Standard settlement window; ideal for higher-ticket invoices, payouts and refunds where instant settlement isn't required.

  2. SCT Inst

    SEPA Instant Credit Transfer

    10-second euro credit transfers between participating banks, 24/7/365. Same authorisation endpoint as SCT; the platform's routing engine picks SCT Inst when the receiving bank supports it.

  3. SDD Core

    SEPA Direct Debit (Core)

    Consumer-side direct debit with mandate authorisation, NACHA-style return codes (R-codes), retry policies and 8-week recall rights. The platform handles mandate IDs, mandate change events and per-cycle dunning.

  4. SDD B2B

    SEPA Direct Debit (B2B)

    Business-to-business direct debit with shorter return windows and no consumer recall rights. Mandate is validated against the payer's bank before the first collection; mandate IDs are carried across each collection cycle.

Key benefits

Why merchants pick this sepa payment gateway shape

Four properties that show up the moment SEPA stops being a side-integration and starts riding the same platform as card and wallet flows.

  1. 01

    One API across the SEPA stack

    SCT, SCT Inst and SEPA Direct Debit ride the same unified API. Switching a payment flow from SCT to SCT Inst, or from card recurring to SDD, is a configuration change rather than a fresh integration.

  2. 02

    Mandate handling without bespoke code

    SEPA Direct Debit mandates capture, validate and store on the platform. Mandate IDs travel with every collection; mandate changes (account moves, BIC updates) flow through the same channel as the original mandate.

  3. 03

    Instant where the receiving bank supports it

    SCT Inst routes preferentially when the receiving bank advertises support; otherwise the engine falls back to SCT inside the same authorise call without the merchant re-encoding.

  4. 04

    Pay-in plus pay-out in one ledger

    Inbound SCT receipts, SDD collections, refund SCTs and merchant payout SCTs normalise into one reconciliation feed — tagged by flow type, mandate ID, currency and partner relationship.

How sepa payment processing works

From mandate or beneficiary to reconciled row, in five steps

What actually happens between the buyer authorising a mandate (or the merchant configuring a beneficiary) and the row in the merchant's general ledger.

  1. 01

    Capture mandate (SDD) or beneficiary (SCT)

    For SDD, the buyer authorises a mandate (online or wet-signature) and the platform stores the mandate ID. For SCT, the merchant configures the beneficiary IBAN once and re-uses it for repeated payouts.

  2. 02

    Issue the authorisation

    POST /v1/authorizations carries the SEPA flavour (sct, sct_inst, sdd_core, sdd_b2b), the amount, currency, mandate ID and reference text. The platform validates IBAN format and BIC reachability before submitting.

  3. 03

    Route through the SEPA partner

    The partner relationship clears the message into the SEPA scheme. SCT Inst routes preferentially when the receiving bank supports it; otherwise the engine clears via SCT and signals the fallback in the event log.

  4. 04

    Handle the lifecycle

    Settlement, return (R-codes for SDD), recall (SCT recall request), refund and chargeback events all fire as signed webhooks. The platform handles R-code-aware retries per merchant policy.

  5. 05

    Reconcile & report

    Settlement files from the SEPA partner normalise into one ledger. Daily exports as CSV or via API; finance imports into the merchant's accounting system tagged by mandate ID, flow type and currency.

Main use cases

Where these sepa payment solutions earn their keep

Six common merchant shapes that benefit from SEPA-rail acceptance and payouts on the same platform as cards and wallets.

  • B2B

    B2B invoicing on SDD B2B

    EU counterparties sign one mandate at contract; recurring invoices collect via SDD B2B with shorter return windows and no consumer recall rights — finance reads predictable cashflow.

  • Sub

    Subscription billing on SDD Core

    Consumer subscriptions paired with SDD Core mandates. R-code-aware retries keep churn-from-NSF down; mandate updates flow without the merchant re-collecting authorisation.

  • Payout

    Mass payouts via SCT and SCT Inst

    Marketplace seller payouts, gig-worker payouts, refunds — SCT for batch payouts, SCT Inst when the receiving bank supports it and instant gratification matters.

  • EU pay-in

    EU buyer pay-in alongside card

    iDEAL, Bancontact and SEPA-area open-banking initiations land into the same merchant ledger as card receipts; SEPA flavours surface as a method on the hosted checkout.

  • Treas

    Treasury operations across euro entities

    Inter-company euro movements between merchant entities on SCT or SCT Inst, tagged with internal references and reconciled into the merchant's general ledger.

  • Refund

    SEPA-side refunds and recalls

    Refund SCTs against the buyer's original IBAN, plus recall flows for SEPA Credit Transfers when supported by the partner — all from the same dispute / refund queue.

Platform features

Capabilities behind pay by sepa payment gateway acceptance

Twelve SEPA-side capabilities the platform exposes — from IBAN validation through to R-code-aware retries, 8-week recall handling and unified reconciliation.

  • Unified API across SCT / SCT Inst / SDD One REST endpoint covers every SEPA flavour; SDKs for web, mobile and server.
  • IBAN validation and BIC lookup Format check, country-code validation and BIC reachability resolution before each authorisation is submitted.
  • SDD mandate capture Hosted mandate-capture page or embedded surface; mandate IDs stored against the merchant's customer record.
  • R-code-aware retries Returns (R-codes) drive per-policy retry behaviour: retry, refund, write-off, dunning sequence.
  • 8-week recall handling (SDD Core) Consumer recall events surface as webhooks; the platform manages return-of-funds against the original mandate.
  • Selective SCT Inst routing Routing engine picks SCT Inst when the receiving bank supports it; transparent fallback to SCT otherwise.
  • PSD2 / SCA orchestration (online) When SEPA-area open-banking initiations involve SCA, the platform orchestrates the redirect and consent flow.
  • Reference text & remittance metadata Free-text reference (max 140 chars per scheme), structured creditor reference (RF-format) and remittance metadata captured per transaction.
  • Multi-currency settlement around SEPA EUR ledger primary; multi-currency settlement supported for non-EUR merchants who want to receive EUR pay-in.
  • Operator-side refund controls Refunds against the original IBAN or via reverse SCT, with operator-side justification and audit logging.
  • Signed webhooks & event log Every status transition (issued, cleared, returned, refunded, recalled) fires a signed event; replay-safe IDs and per-merchant signing secret.
  • One reconciliation feed SCT receipts, SCT Inst confirmations, SDD collections, R-code returns, refunds and recalls all in one normalised ledger.

Industry relevance

Built for licensed EU, UK and EEA merchants moving euro

topropay's SEPA-side posture targets licensed merchants moving euro across the SEPA area — B2B invoicing on SDD B2B, consumer subscriptions on SDD Core, mass payouts on SCT and SCT Inst, and EU buyer pay-in alongside card on the hosted checkout.

  • B2B invoicing · SDD B2B
  • Subscriptions · SDD Core
  • Mass payouts · SCT & SCT Inst
  • EU buyer pay-in alongside card
  • Treasury operations across EU entities
  • Licensed gaming · where licensed
  • Adult-content acceptance · out of scope
  • Unlicensed gambling · out of scope

Trust & compliance

Compliance posture across every SEPA flavour

One audited environment plus SEPA-scheme rulebook adherence. Sub-merchants inherit the relevant posture without carrying separate certifications themselves.

PSD2 / SCA
PSD2 strong customer authentication applied on initiation flows that fall under SCA; selective challenges to keep approval high.
SEPA Scheme Rulebooks
Authorisation, clearing, return and recall flows follow the European Payments Council (EPC) SEPA scheme rulebooks — SCT, SCT Inst, SDD Core and SDD B2B.
GDPR & data residency
Mandate records and SEPA event logs stored within EU data residency boundaries by default; per-merchant data-residency overrides on request.
Sanctions & AML alignment
Sanctions screening at onboarding; SEPA-side IBAN-level sanctions checks integrated into the authorisation path.
PCI DSS Level 1 (cross-channel)
Where a merchant runs card alongside SEPA, the same PCI DSS Level 1 vault and tokenisation posture applies; the unified ledger spans both rails.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of rail.

Ready to add SEPA

Add the SEPA payment system to your stack without forking it.

A 30-minute SEPA review covers the flavours relevant to your flows (SCT, SCT Inst, SDD Core, SDD B2B), mandate-capture mechanics for your customer base, and a sandbox you can test against before any commercial commitment.

Book a SEPA review Read the API docs

Frequently asked

Buyer questions about the sepa payment system on topropay

Definitions, SCT vs SCT Inst differences, mandate mechanics, R-code retries, recall windows and the practicalities of running SEPA alongside card and wallet rails.

  1. 01

    What does the sepa payment system on topropay cover?

    The sepa payment system on topropay covers SCT (SEPA Credit Transfer), SCT Inst (SEPA Instant Credit Transfer), SDD Core (consumer Direct Debit) and SDD B2B (business Direct Debit) through one unified API. Pay-in receipts, recurring debits, mass payouts and refunds all share the same authorise endpoint and reconciliation feed.

  2. 02

    Is sepa payment method exposed alongside card on the hosted checkout?

    Yes. SEPA payment method options surface on the hosted checkout alongside cards and other regional rails. SDD Core is offered for recurring buyer flows; SCT-based pay-in via open-banking initiation is offered as a one-off bank-rail alternative to card.

  3. 03

    How does the sepa payment gateway side of the platform work?

    The sepa payment gateway role is filled by topropay's unified gateway — one API contract in front of the connected SEPA-partner relationships. The merchant integrates once; the partner network handles scheme-side clearing for SCT, SCT Inst, SDD Core and SDD B2B.

  4. 04

    What sepa payment solutions are available for recurring billing?

    SEPA payment solutions for recurring billing centre on SDD Core for consumers and SDD B2B for businesses. Mandate IDs travel with each collection; R-code-aware retries handle NSF and other return codes; dunning sequences template per merchant. Network-token card recurring sits alongside, in the same dashboard, for hybrid card-plus-SEPA portfolios.

  5. 05

    What does sepa payment processing look like end-to-end?

    SEPA payment processing on topropay starts with mandate capture (for SDD) or beneficiary configuration (for SCT). Authorisations flow through the unified API, the partner clears into the SEPA scheme, lifecycle events fire as signed webhooks (settlement, return, recall, refund), and settlement files normalise into the reconciliation feed.

  6. 06

    Can buyers pay by sepa payment gateway directly from their bank?

    Yes. Pay-by-bank-style flows surface on the hosted checkout where SEPA-area open-banking initiation is supported — the buyer is redirected to their bank, approves the payment via the bank's SCA flow, and the platform receives the initiated SCT as an authorisation in the merchant's account.

  7. 07

    What's the difference between SCT and SCT Inst on the platform?

    SCT is a single-leg SEPA Credit Transfer on the standard settlement window (typically next-business-day end-to-end). SCT Inst settles in under 10 seconds, 24/7/365, between participating banks. The platform's routing engine picks SCT Inst when the receiving bank supports it and falls back to SCT transparently when it doesn't — the merchant doesn't pick per-transaction.

  8. 08

    How are SEPA Direct Debit mandates captured?

    SEPA Direct Debit mandates are captured either through the platform's hosted mandate page (the buyer signs online, the platform stores the mandate ID and PDF) or via an embedded surface in the merchant's own flow. For SDD B2B, the platform additionally validates the mandate against the payer's bank before the first collection.

  9. 09

    What happens when a SEPA Direct Debit is returned?

    When a SEPA Direct Debit is returned, the partner relays the SEPA R-code (R01 'insufficient funds', R02 'account closed', R05 'unauthorised' and so on). The platform fires a signed webhook with the R-code, and the merchant's configured retry / dunning policy executes — retry on a different day, send a dunning email, or write off the collection.

  10. 10

    How long is the SDD Core consumer recall window?

    SDD Core consumers have an 8-week unconditional refund right after the collection date, and up to 13 months if the collection was unauthorised. The platform manages return-of-funds against the original mandate when a recall fires and surfaces the event in the dispute queue for the merchant's review.

  11. 11

    Can the platform handle SEPA payouts at scale?

    Yes. Mass SEPA payouts via SCT or SCT Inst are a supported flow — batch payouts to seller IBANs, gig-worker payouts, refund payouts. Each payout produces a settlement row in the unified ledger; failed payouts (invalid IBAN, account closed) surface as events for the merchant's payout-ops team.

  12. 12

    Does the SEPA flow work for non-EUR merchants?

    Yes. Non-EUR merchants who want to accept EUR pay-in via SEPA can do so; the platform converts on settlement to the merchant's preferred currency (FX rate per the partner's published spread). The merchant's reconciliation feed still tags every SEPA row with original EUR and converted currency.

  13. 13

    Are SEPA mandate records GDPR-compliant?

    SEPA mandate records and the associated event log are stored within EU data-residency boundaries by default. Per-merchant data-residency overrides are available on request. GDPR data-subject rights (access, rectification, erasure where SEPA scheme rules permit) are handled via the platform's data-subject-request workflow.

  14. 14

    What integration timeline should we expect for SEPA?

    Most merchants move from contract to first SEPA transaction in 2–4 weeks. The variables are KYB depth, the SEPA partner's underwriting timeline, and the merchant's PCI-or-not scope (if card is being added alongside SEPA). Sandbox covers the full SEPA flow from day one.

  15. 15

    How does SEPA pair with the wider topropay platform?

    SEPA pairs with the wider topropay platform as one of the supported payment-system types — alongside card, wallet, BNPL, crypto and other regional bank rails. The same routing engine, vault, dispute queue and reconciliation feed apply across rails; the merchant's accounting system sees one ledger regardless of which rail cleared a given receipt.

Related

Related on the topropay platform