Giropay Germania: online banking

1) giropay context și poziționare

giropay - schema germană A2A „pay-by-bank”, în cazul în care cumpărătorul confirmă plata în banca sa online/aplicația mobilă a băncii emitente. Comerciantul primește statut online, iar banii vin cu un împrumut bancar (de obicei T + 0/T + 1 zile lucrătoare, în funcție de banca/PSP și șina de decontare utilizată). Costul primirii este mai mic decât un MDR tipic cardului, SCA se efectuează la emitent în conformitate cu PSD2.

• Issuer-redirect/App2App: redirecționați către o bancă sau deschideți aplicația acesteia.
• SCA și dispozitiv obligatoriu: confirmarea de la bancă, minimizarea fraudei.
• Metadate bogate pentru reconciliere: referință comerciant/comandăID, tranzacțieID.
• Rambursare prin transfer de credit: nu există chargeback ca în carduri.

2) Roluri și participanți

Schema Giropay - reguli, rutare către bănci.
Emitent (banca platitorului) - autentificare client, confirmare, limite/antifrauda.
PSP/Acquirer (CPSP) - conexiune comercială, API/SDK, cărți web, rapoarte și calcule.
Comerciant - initiere plata, prelucrare stare/retur, reconciliere.

3) Fluxurile de plată

3. 1 Emitent clasic-redirecționare (web)

1. Checkout comerciant → giropay selecție.
2. Lista băncilor → redirecționa către banca online → SCA/confirmare.
3. Întoarceți-vă la site-ul comerciantului cu statutul (succes/în așteptare/eșuat/anulat/expirat).
4. Așteptarea pentru webhook/registru despre creditul real (decontare).

3. 2 App2App (mobil)

La telefon, comerciantul deschide aplicația bancară prin deeplink/intenție → confirmare → returnare.
Conversia este de obicei mai mare; rezervă necesară la redirecționarea web.

3. 3 QR/Pay-by-Link

PSP poate oferi un QR/link dinamic cu suma și referința (convenabil pentru facturi/offline).
Utilizatorul scanează codul și îl confirmă băncii în conformitate cu schema de mai sus.

3. 4 „Prima plată → mandat”

Pentru facturarea recurentă, giropay este adesea folosit ca prima plată cu SCA, iar apoi - SEPA Direct Debit/mandat open-banking pentru scrierea ulterioară.

4) Autorizare vs decontare

Online- статусы: „succes”, „în așteptare”, „eșuat”, „anulat”, „expirat”.
„în așteptare” înseamnă că banca/furnizorul confirmă în continuare tranzacția sau că se așteaptă un împrumut.
Decontare: credit real pe PSP/rapoarte bancare (de obicei T + 0/T + 1; în unele cazuri mai mult).
Pentru serviciile sensibile la risc, utilizați modelul „performanță condiționată” înainte de înscrierea confirmată.

5) Returnări și dispute

Nu există Încărcătoare. Returul este o nouă tranzacție de credit de la comerciant la plătitor (sunt posibile returnări parțiale).
Datele de retur - banca (T + 0/T + 1/T + 2, depinde de canal).
Litigii/reclamații - prin proceduri SOL PSP și banca plătitorului; pregătiți jurnalele comenzii, dovada livrării/serviciilor.

6) Limite și politici de risc

• Per-tranzacție, pe zi/săptămână у issuer'а.
• Noi destinatari/comercianți - praguri reduse și/sau expunere.
• Reguli de canal/viteză, semnale geo/dispozitiv, excepții SCA (TRA/RA) - la discreția băncii.

Practică: Nu hardcode numere. Păstrați un director de limite de bancă/canal, actualizați-l, afișați motive clare pentru eșecuri („limită bancară/canal depășită”) și oferiți alternative (verificare divizată, altă metodă).

7) Comisioane și economie

Pentru giropay, un procent fix/scăzut este de obicei aplicat la adresa PSP; sub harta MDR.
Luați în considerare cheltuielile în așteptare/cheltuieli, SOL și sprijin de recunoaștere, precum și taxele pentru widget-uri găzduite/încorporate și raportare.

8) Reconciliere și raportare

Store: 'paymentId/transactionId' al furnizorului,' orderId', emitent bank, time, channel (Redirect/App2App/QR), status final, bank reference/UTR from fin reports.
Activați cărțile web despre modificările de stare, auto-recunoașterea zilnică și recunoașterea completă periodică (credite/returnări/corecții).
Configurați alerte desincronizate și tablouri de bord SLA.

9) Modele UX

Directorul băncilor: auto-indiciu/căutare, memorarea ultimei bănci.
Mobile-first: oferta App2App; rezervă - redirecționare web.
Erori și repetiții: motive clare (limită, eșec SCA, timeout), încercare sigură cu idempotență.
Primire: suma, data/ora, 'tranzactionId', banca, canal, suport link.

10) Reduceri recurente

Utilizați schema: prima plată giropay → e-mandat (SEPA DD/Open Banking).
În bilet, fixați limita de debit, frecvența, notificările și gestionarea (pauză/anulare).

11) Conformitate și siguranță

PSD2/SCA se efectuează la bancă; legarea dispozitivelor și antifrauda pe partea emitentului.
Minimizarea GDPR/PII: stocați numai atributele necesare, criptați PII, restricționați accesul.
Webhooks: HMAC/nonce, protecție reluare, IP allowlist, jurnal de audit.

12) verticale sensibile (inclusiv iGaming)

disponibilitatea și limitele giropay depind de politica PSP/bancară și de legislația locală.
Așteptați praguri reduse, KYC extins și posibilele dețineri.
Planificați șine alternative (carduri, SEPA, alte PiS open-banking), rutare inteligentă în funcție de profilul clientului.

13) Integrarea comerciantului: Opțiuni

1. Hosted/Embedded from PSP - lansare rapidă, listă gata făcută de bănci, statusuri, erori.
2. Server-to-Server + Redirect/App2App - propria pagină de selecție a băncii, procesarea erorilor profunde, propria legătură QR/Deep.
3. Facturi/Rau-by-Link/QR - convenabil pentru B2B/offline.

• API: 'createPayment', 'queryStatus', 'rambursare', 'webhook', 'reconciliere'.
• Idempotence (orderId + key), retray exponențial, eveniment dedup.
• Cataloage: bănci/limite/coduri de eroare; Valorile SLA de către emitenți.

14) arhitectura „Giropay Gateway”

Strat API (REST/GraphQL) pentru casa de marcat.
Cozi de evenimente: evenimente de stare → facturare/CRM/analytics.
Observabilitate: conversie bancă/canal, 'pending→success/expired', latență la decontare.
Securitate: seif pentru secrete, IP-allowlist PSP, validare strictă redirect-URI, jetoane anti-reluare.

15) Lista de verificare de ieșire

1. Selectați canalul PSP/giropay (Hosted/Embedded/App2App/QR), conveniți asupra tarifelor și SLA-urilor.
2. Implementați 'createPayment' + selecție bancară + redirecționare/App 2 App cu rezervă.
3. Conectați webhooks, timeout-uri și recuperări de stare.
4. Configurați recunoașterea (zilnică + completă), stocarea referințelor UTR/fin.
5. Activați rambursările parțiale/complete și SOL în suport.
6. Pregătiți scenarii de eșec/limită UX și metode alternative.
7. Acoperiți băncile mobile (iOS/Android) și emitenții majori cu teste.

Carte de reper

Статусы: „succes”, „în așteptare”, „eșuat”, „anulat”, „expirat”.
Decontare: mai des T + 0/T + 1; ia în considerare performanța condiționată înainte de credit.
Limite: per-txn/zi/săptămână la emitent 'a; pentru noii beneficiari - praguri reduse.
Recurență: prin e-mandat/SEPA DD/Open Banking după prima plată A2A.

Rezumat

Pariați pe App2App/Embedded de conversie și pe QR/Pay-by-Link dinamic pentru facturi/offline.
Confirmarea online separată și creditul real în logica de afaceri.
Nu sumele de cod greu: păstrați configurațiile limită de bancă/canal și actualizați în mod regulat.
Construiți un proces în jurul webhooks + recunoaștere, retururi parțiale și manipularea clară a „în așteptare/expirat”.