Giropay Germany: online banking

1) giropay context and positioning

giropay - German A2A "pay-by-bank" scheme, where the buyer confirms the payment in his online bank/mobile application of the issuing bank. Merchant receives online status, and the money comes with a bank loan (usually T + 0/T + 1 working days, depending on the bank/PSP and the settlement rail used). The cost of receiving is lower than a typical card MDR, SCA is performed at the issuer in accordance with the PSD2.

• Issuer-redirect/App2App: redirect to a bank or open its application.
• SCA and device binding: confirmation from the bank, minimizing fraud.
• Rich metadata for reconciliation: merchant reference/orderId, transactionId.
• Refund via credit transfer: there is no chargeback as in the cards.

2) Roles and participants

Giropay scheme - rules, routing to banks.
Issuer (payer's bank) - client authentication, confirmation, limits/anti-fraud.
PSP/Acquirer (CPSP) - merchant connection, API/SDK, webhooks, reports and calculations.
Merchant - payment initiation, status/return processing, reconciliation.

3) Payment flows

3. 1 Classic issuer-redirect (web)

1. Checkout merchant → giropay selection.
2. List of banks → redirect to online bank → SCA/confirmation.
3. Return to the merchant's site with the status (success/pending/failed/canceled/expired).
4. Waiting for the webhook/registry about the actual credit (settlement).

3. 2 App2App (mobile)

On the phone, the merchant opens the banking application by deeplink/intent → confirmation → return.
Conversion is usually higher; required fallback to web redirect.

3. 3 QR/Pay-by-Link

The PSP can give a dynamic QR/link with the amount and reference (convenient for invoices/offline).
The user scans the code and confirms it to the bank according to the scheme above.

3. 4 "First payment → mandate"

For recurring billing, giropay is often used as the first payment with SCA, and then - SEPA Direct Debit/open-banking mandate for subsequent write-offs.

4) Authorization vs settlement

Online-статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
'pending'means that the bank/provider is still confirming the transaction or a loan is expected.
Settlement: actual credit on PSP/bank reports (usually T + 0/T + 1; in some cases longer).
For risk-sensitive services, use the "conditional performance" model prior to confirmed enrollment.

5) Returns and disputes

There are no Chargers. The return is a new credit transaction from the merchant to the payer (partial returns are possible).
Return dates - bank (T + 0/T + 1/T + 2, depends on the channel).
Disputes/complaints - through PSP ODR procedures and payer's bank; prepare order logs, proof-of-delivery/services.

6) Limits and risk policies

• Per-transaction, per-day/week у issuer’а.
• New recipients/merchants - reduced thresholds and/or exposure.
• Channel/velocity rules, geo/device signals, SCA exceptions (TRA/RA) - at the discretion of the bank.

Practice: Don't hardcode numbers. Keep a directory of limits by bank/channel, update it, show clear reasons for failures ("exceeded bank/channel limit") and offer alternatives (split check, other method).

7) Commissions and Economics

For giropay, a fix/low percentage is usually applied to the PSP address; below the map MDR.
Consider spending on pending/expiries, ODR and recon support, as well as fees for hosted/embedded widgets and reporting.

8) Reconciliation and Reporting

Store: 'paymentId/transactionId' of the provider, 'orderId', issuer bank, time, channel (Redirect/App2App/QR), final status, bank reference/UTR from fin reports.
Enable webhooks about status changes, daily auto-recon and periodic full-recon (credits/returns/corrections).
Set up desynchronized alerts and SLA dashboards.

9) UX patterns

Directory of banks: auto-hint/search, memorization of the last bank.
Mobile-first: offer App2App; fallback - web redirect.
Errors and repetitions: clear reasons (limit, SCA failure, timeout), safe-retry with idempotency.
Receipt: amount, date/time, 'transactionId', bank, channel, support link.

10) Recurrent write-offs

Use the scheme: first payment giropay → e-mandate (SEPA DD/Open Banking).
In the ticket, fix the per debit limit, frequency, notifications and management (pause/cancel).

11) Compliance and safety

PSD2/SCA is performed at the bank; device binding and anti-fraud on the issuer side.
GDPR/PII minimization: store only the necessary attributes, encrypt PII, restrict access.
Webhooks: HMAC/nonce, replay protection, allowlist IP, audit log.

12) Sensitive verticals (including iGaming)

giropay availability and limits depend on PSP/bank policy and local law.
Expect reduced thresholds, extended KYC and possible holds.
Plan alternative rails (cards, SEPA, other open-banking PIS), smart-routing according to the client's profile.

13) Merchant Integration: Options

1. Hosted/Embedded from PSP - quick launch, ready-made list of banks, statuses, errors.
2. Server-to-Server + Redirect/App2App - own bank selection page, deep error processing, own QR/Deep Link.
3. Invoices/Rau-by-Link/QR - convenient for B2B/offline.

• API: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotence (orderId + key), retray exponentially, event dedup.
• Catalogs: banks/limits/error codes; SLA metrics by issuers.

14) "giropay Gateway" architecture

API layer (REST/GraphQL) for the cash register.
Event queues: status events → billing/CRM/analytics.
Observability: bank/channel conversion, 'pending→success/expired', latency to settlement.
Security: vault for secrets, IP-allowlist PSP, strict redirect-URI validation, anti-replay tokens.

15) Output checklist

1. Select PSP/giropay channel (Hosted/Embedded/App2App/QR), agree on tariffs and SLAs.
2. Implement 'createPayment' + bank selection + redirect/App 2 App with fallback.
3. Connect webhooks, timeouts and status retrievals.
4. Set up recon (daily + full), UTR/fin references storage.
5. Enable partial/full refunds and ODR in support.
6. Prepare UX failure/limit scenarios and alternative methods.
7. Cover mobile banks (iOS/Android) and major issuers with tests.

Landmark card

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: more often T + 0/T + 1; consider conditional performance before credit.
Limits: per-txn/day/week at issuer'a; for new recipients - reduced thresholds.
Recurrence: via e-mandate/SEPA DD/Open Banking after the first A2A payment.

Summary

Bet on conversion App2App/Embedded and dynamic QR/Pay-by-Link for invoices/offline.
Separate online confirmation and actual credit in business logic.
Do not hard code amounts: keep limit configs by bank/channel and update regularly.
Build a process around webhooks + recon, partial returns and clear handling of'pending/expired'.