Skip to content

Payments and cards

Module id: payments

Payment orders and card records. Networks and providers stay behind ports.

There is no domain-banking-payments and no exp-payments. Card journeys are the experience service that exists today. Payment orders are a core record.

Payments, read top to bottom: card journeys, card domain, payment and card records, then provider and rail ports
Read top to bottom. The channel runs card journeys. The domain coordinates cards. The core stores payment orders and card records. Ports reach providers and rails.

The provider port is PspAdapter in library-psps. The rail port is RailAdapter in library-rails. See adapter ports for how to read that picture. core-payments-engine is on disk as provider-agnostic orchestration and has no published OpenAPI.

What it owns

  • Payment orders, instructions, beneficiaries, methods, schedules, and fees
  • Card records, programmes, limits, transactions, and issuance journeys
  • Account-information and payment-initiation records for open banking
  • The provider port and the rail port

What it does not own

  • Ledger postings. Those are accounts.
  • Revolving credit servicing agreements. Those are lending (core-lending-credit-cards).
  • A named network or processor toolkit. That stays in an adapter, not in the domain.
  • The party. That is customers.

Repositories

Repository Layer What it holds OpenAPI
exp-cards Experience Card issuance, card replacement, cards by customer openapi.yml
domain-banking-cards Domain Cards, virtual cards, limits, credit line, transactions, security openapi.yml
core-banking-payments Core Payment orders, beneficiaries, methods, schedules, fees openapi.yml
core-banking-cards Core Cards, programmes, limits, transactions, issuers openapi.yml
core-banking-psdx Core Consents, account information, payment initiation, funds confirmation openapi.yml
core-payments-engine Core Orchestration of disbursements and inbound payments No published OpenAPI yet
library-psps Port Provider port Java interfaces, not OpenAPI
library-rails Port Rail port Java interfaces, not OpenAPI

How the pieces fit

exp-cards exposes issuance and replacement journeys, and cards for a customer. That is the channel edge that exists. Payment orders do not have a matching experience repository.

domain-banking-cards coordinates cards, limits, virtual cards, the credit line, transactions, and security, including a back-office view.

core-banking-payments persists orders, instructions, beneficiaries, methods, schedules, fees, proofs, and exchange rates. core-banking-cards persists the card record: programmes, limits, transactions, balances, issuers, and related card resources in that spec. core-banking-psdx persists consents, strong authentication steps, account information, payment initiation, and funds confirmation. Those records are operational. They are not a statement that an institution meets a regulation.

Outbound calls leave through library-psps or library-rails. Domain code depends on the port. The adapter implements it for one provider or one rail. core-payments-engine is described in its README as orchestration that is independent of a provider and a rail. Treat the missing OpenAPI as a gap.