Local Payment Methods

Each rail is an isolated collection so per-method invariants are explicit. SwishPaymentRequest holds the swish_instruction_uuid, payee_alias, payer_alias, amount as Decimal, currency=SEK (validated), message (max 50 chars), status (created, paid, declined, error, cancelled), base64 QR code data, callback_url, and SwishPaymentMetadata; Swish callbacks land at POST /swish/callbacks/, are idempotency-checked by callback_identifier, and on PAID create both Payment and Receipt while updating the request. iDEAL and Bancontact share a similar shape with provider (stripe or mollie), bank metadata (BIC for iDEAL, cardholder language for Bancontact), EUR-only validation, and webhook-driven Payment+Receipt creation on succeeded. Bizum mirrors the model with provider (stripe or redsys), payer_phone, base64 QR data, and EUR-only validation.

SepaDirectDebitPayment is the most elaborate — mandate_id with mandate_status (pending, active, revoked, expired), debtor_iban, debtor_name, creditor_id, sequence_type (OOFF, RCUR, FRST, FNAL), description capped at 140 chars per SEPA rules, and a return_code field that captures the full R01–R99 SEPA return-code spectrum so reversals can be diagnosed. KlarnaPayment supports purchase_country across 18 jurisdictions, multi-currency (EUR, SEK, NOK, DKK, GBP, USD, CHF, PLN, CZK), payment_type (pay_later, pay_over_time, direct_debit, direct_bank_transfer), installment_count between 2 and 36, and a two-stage authorize→capture flow. All rails expose CRUD with status/invoice_id filters, dedicated sync endpoints to pull provider state on demand, and webhook endpoints with idempotency to absorb retries without double-booking payments.