Payments and book transfers

Start with the Transfer workflow for connection choice, external execution and recovery. Internal account movement uses the core’s own balanced posting contract.

Internal transfers

POST /accounttransfers consumes source/destination office, customer, account and account-type identities under its source schema. The self-service variant /self/accounttransfers uses customer scope. Inspect the exact fields and authority rules in the reference.

Current book transfers reject a supplied cashierId or tellerId. Physical cash needs its own custody and posting workflow. Keep the same durable business identity and the operation’s actual idempotency mechanism across retries. A header name by itself supplies no guarantee for every legacy endpoint.

External transfers

The source /payment-transfers family and selected local NGN/NPS profile use their own route, payee, request, approval, outcome, settlement and reconciliation contracts. The legacy /transfers/send route remains structurally blocked.

Choose Local banking profile in the API reference for that separately scoped contract. Use synthetic fixtures in the named local environment. Approval, core funding, external acceptance, customer completion and final reconciliation remain separately visible.

Recover without duplicating value

If a submission response is lost, query authoritative status using the original instruction. Retain the original route while its outcome is unknown. An operator uses external enquiry and reconciliation before any further dispatch or customer compensation. Returns, recalls and fee treatment have separate linked evidence.

The institution’s owner must qualify the exact currency, fee, route, authority and provider arrangement. Cross-border and stablecoin target scope requires additional contracts and acceptance beyond the local profile.