Payment Processing

Each payment is anchored to an Invoice and progresses through a tracked status lifecycle written to /payments/. Online card and bank-debit settlement runs through Stripe Checkout: clients call POST /checkout/ with gateway=stripe, the user is redirected to Stripe Checkout, and the platform listens on POST /webhooks/stripe for checkout.session.completed (creates Payment, updates Invoice, generates receipt, distributes revenue), checkout.session.expired (marks the session expired) and payment_intent.payment_failed (flags failure). Swedish payers can pay by Swish; POST /checkout/ with gateway=swish returns a base64 QR payload, the Swish app posts back to /webhooks/swish, and the same Payment-creation pipeline executes.

Bank transfers settle through the Bank Reconciliation subsystem, which writes Payment rows when an inbound BGI line matches an Invoice OCR reference. Receipt PDFs are emitted on demand via /receipts/{id}/pdf. Refunds run through /payments/{id}/gateway-refund, which reverses the original Stripe charge or Swish settlement and writes a corresponding negative Payment.

Multi-currency support stores both transaction currency and tenant base currency on every Payment, with the ECB reference rate frozen at invoice-issue time to keep historical conversions reproducible. Club bulk payment lets a club treasurer settle every member licence in one Stripe session that fans out into per-member Payment rows. Per-tenant payment gateways are configured via /payment-gateways/, with credentials stored as Azure Key Vault references rather than plaintext secrets.

Every Payment writes a structured audit row queryable through /payment-history/{debtor_id}, and the entire pipeline is idempotent on Stripe event id and Swish callback id to survive webhook replays.