Giropay Allemagne : banque en ligne

1) Le contexte et le positionnement de giropay

giropay est un régime allemand A2A « pay-by-bank » où l'acheteur confirme le paiement dans sa banque en ligne/application mobile de la banque émettrice. Le merchant obtient le statut en ligne et l'argent vient par crédit bancaire (généralement T + 0/T + 1 jours ouvrables, dépend de la banque/PSP et du rail de règlement utilisé). Le coût de réception est inférieur à la carte MDR typique, SCA est effectué chez l'émetteur selon le PSD2.

• Issuer-redirect/App2App : redirection sur la banque ou ouverture de son application.
• SCA et binding de device : confirmation auprès de la banque, minimisation de la fronde.
• Métadonnées riches pour le rapprochement : merchant reference/orderId, transactionId.
• Refund via le virement : chargback comme dans les cartes.

2) Rôles et participants

Le schéma giropay - les règles, l'itinérance des banques.
Issuer (banque du payeur) - authentification du client, confirmation, limites/antifrod.
PSP/Acquirer (CPSP) - connexion de merchant, API/SDK, webhooks, rapports et calculs.
Merchant - Initiation du paiement, traitement des statuts/retours, rapprochement.

3) Flux de paiement

3. 1 Classic issuer-redirect (web)

1. Checkout merchant → sélection giropay.
2. Liste des banques → redirect à la banque en ligne → SCA/confirmation.
3. Retour sur le site du merchant avec statut (success/pending/failed/canceled/expired).
4. En attente de webhook/registre sur le crédit réel (settlement).

3. 2 App2App (mobile)

Sur le téléphone, le merchant ouvre l'application bancaire deeplink/intent → la confirmation → le retour.
La conversion est généralement plus élevée ; obligatoire fallback sur le web redirect.

3. 3 QR/Pay-by-Link

PSP peut donner un QR/référence dynamique avec somme et référence (pratique pour les factures/offline).
L'utilisateur scanne le code et confirme à la banque selon le schéma ci-dessus.

3. 4 « Premier paiement → mandat »

Pour les facturations récurrentes, giropay est souvent utilisé comme premier paiement avec SCA, puis - SEPA Direct Debit/open-banking mandat pour les débits ultérieurs.

4) Statuts et calculs (autorisation vs établissement)

Online-статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Le terme « pending » signifie que la banque/le fournisseur confirme encore l'exécution ou le prêt attendu.
Settlement : inscription réelle selon les rapports PSP/banque (généralement T + 0/T + 1 ; dans certains cas, plus longtemps).
Pour les services sensibles au risque, utiliser le modèle « exécution conditionnelle » avant l'inscription confirmée.

5) Retours et disputes

Il n'y a pas de Charjbacks. Les retours sont une nouvelle opération de crédit du merchant au payeur (remboursements partiels possibles).
Les délais de retour sont bancaires (T + 0/T + 1/T + 2, selon le canal).
Disputes/plaintes - par le biais des procédures ODR du PSP et de la banque du payeur ; préparer les logs de commande, proof-of-delivery/services.

6) Limites et politiques de risque

• Per-transaction, per-day/week у issuer’а.
• Nouveaux destinataires/merchants - seuils réduits et/ou vitesse d'obturation.
• Les règles de canal/velocity, les signaux géo/devis, les exceptions SCA (TRA/RA) sont à la discrétion de la banque.

Pratique : ne hardcodez pas les chiffres. Tenez un répertoire des limites par banque/canal, mettez-le à jour, montrez les raisons compréhensibles des refus (« limite banque/canal dépassée ») et proposez des alternatives (casser le chèque, autre méthode).

7) Commissions et économie

Pour giropay, un fix/faible pourcentage est généralement appliqué à l'adresse du PSP ; en dessous de la carte MDR.
Tenez compte des frais de support pending/expiries, ODR et recon, ainsi que des frais d'hébergement/embedded-widgets et de reporting.

8) Rapprochement et établissement de rapports

Stockez : 'paymentId/transactionId' fournisseur, 'orderId', banque-issuer, heure, canal (Redirect/App2App/QR), état final, référence bancaire/UTR des rapports finaux.
Activez webhooks sur le changement de statut, daily auto-recon et périodique full-recon (crédits/retours/corrections).
Configurez les alertes par dissynchrones et dashboards SLA.

9) Modèles UX

Annuaire des banques : Histoire automatique/recherche, mémorisation de la dernière banque.
Mobile-first : offrir des App2App ; fallback est un redirect web.
Erreurs et répétitions : raisons claires (limite, refus de SCA, délai), safe-retry avec idempotence.
Reçu : montant, date/heure, 'transactionId', banque, canal, référence de sapport.

10) Déclassements récurrents

Utilisez le schéma : premier paiement giropay → e-mandate (SEPA DD/Open Banking).
Dans le mandat, fixez la limite par débit, la fréquence, les notifications et la gestion (pause/cancel).

11) Conformité et sécurité

PSD2/SCA est effectuée dans une banque ; device binding et antifrod sur le côté issuer'a.
Minimisation GDPR/PII : ne stockez que les attributs nécessaires, cryptez PII, limitez l'accès.
Webhooks : HMAC/nonce, protection contre le replay, IP allowlist, journal d'audit.

12) Verticales sensibles (y compris iGaming)

L'accessibilité et les limites de giropay dépendent de la politique PSP/banques et du droit local.
Attendez-vous à des seuils réduits, KYC étendu et hold's possibles.
Prévoyez des rails alternatifs (cartes, SEPA, autres PIS open banking), un routage intelligent par profil client.

13) Intégration du merchant : options

1. Hosted/Embedded de PSP - démarrage rapide, liste prête des banques, statuts, erreurs.
2. Server-to-Server + Redirect/App2App est votre propre page de sélection de banque, la gestion profonde des erreurs, propre QR/Deep Link.
3. Factures/Rau-by-Link/QR - pratique pour B2V/offline.

• API: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotence (orderId + clé), retraits par exposant, déduplication des événements.
• Catalogues : banques/limites/codes d'erreur ; Métriques SLA par issuer'am.

14) Architecture « giropay Gateway »

Couche API (REST/GraphQL) pour la caisse.
Files d'attente d'événements : États-participants → facturation/CRM/analyse.
Observability : conversion par banques/canaux, « pending→success/expired », latence avant settlement.
Sécurité : vault pour les secrets, IP-allowlist PSP, validation stricte de redirect-URI, jetons anti-replay.

15) Chèque-liste de sortie dans la prod

1. Sélectionnez PSP/canal giropay (hébergé/embarqué/App2App/QR), accepter les tarifs et SLA.
2. Implémentez 'createPayment' + sélection banque + redirect/Arr2Arr avec fallback.
3. Connectez les webhooks, les délais et les répétitions d'obtention des statuts.
4. Configurez recon (daily + full), stockage UTR/fin-références.
5. Inclure partial/full refunds et la réglementation ODR dans le saphport.
6. Préparez des scénarios UX d'échec/limites et d'autres méthodes.
7. Couvrir avec des tests les banques mobiles (iOS/Android) et les principaux issuer's.

Carte de repères

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement : Plus souvent T + 0/T + 1 ; tenir compte de l'exécution conditionnelle avant le prêt.
Limites : per-txn/day/week chez issuer'a ; pour les nouveaux bénéficiaires, des seuils réduits.
Récurrence : via e-mandate/SEPA DD/Open Banking après le premier paiement A2A.

Résumé

Pariez sur le App2App/Embedded pour la conversion et sur le QR/Pay-by-Link dynamique pour les factures/offline.
Partagez la confirmation en ligne et le crédit réel dans la logique d'entreprise.
N'encodez pas rigidement les montants : gardez les limites configues sur les banques/canaux et mettez à jour régulièrement.
Construisez le processus autour de webhooks + recon, les retours partiels et le traitement clair 'pending/expired'.