Support payment lifecycle events for gobank-products integration #1

New issue

Open

opened 2026-08-07 14:23:39 +00:00 by hum3 · 0 comments

hum3 commented

2026-08-07 14:23:39 +00:00

Owner

Context

gobank-products models customer-initiated events (deposits, withdrawals) as synchronous book transfers — the simulation records a ledger movement immediately and returns success or error. There is no concept of payment failure, timeout, or asynchronous settlement.

In production, deposits arrive as inbound FPS credits and withdrawals are outbound FPS debits. The full payment lifecycle has states beyond "requested" and "completed".

What mock-fps should provide

A payment scheme simulation that models:

Payment initiation — submitting a payment to the scheme
Asynchronous settlement — configurable delay between submission and confirmation
Payment failure modes — timeout, rejection, insufficient funds at counterparty, scheme-level errors
Payment return — FPS return after initial credit (e.g. fraud recall)
Reconciliation — matching inbound scheme messages to expected transactions

Integration boundary

gobank-products: product rules, interest, lifecycle, ledger movements (assumes payments succeed)
mock-fps: payment scheme simulation, failure modes, async settlement, reconciliation

What gobank-products would need to change

To integrate with mock-fps, gobank-products would need to:

Accept a payment outcome event (success/failure) rather than recording movements directly in DepositAcceptance / WithdrawalProcessing
Model a PendingPayment state between initiation and settlement
Handle payment reversals

This is not urgent — the current synchronous model is correct for simulation and testing. This issue tracks the eventual integration point.

Migrated from Codeberg: originally #1, opened 2026-03-17.

## Context gobank-products models customer-initiated events (deposits, withdrawals) as synchronous book transfers — the simulation records a ledger movement immediately and returns success or error. There is no concept of payment failure, timeout, or asynchronous settlement. In production, deposits arrive as inbound FPS credits and withdrawals are outbound FPS debits. The full payment lifecycle has states beyond "requested" and "completed". ## What mock-fps should provide A payment scheme simulation that models: 1. **Payment initiation** — submitting a payment to the scheme 2. **Asynchronous settlement** — configurable delay between submission and confirmation 3. **Payment failure modes** — timeout, rejection, insufficient funds at counterparty, scheme-level errors 4. **Payment return** — FPS return after initial credit (e.g. fraud recall) 5. **Reconciliation** — matching inbound scheme messages to expected transactions ## Integration boundary - **gobank-products**: product rules, interest, lifecycle, ledger movements (assumes payments succeed) - **mock-fps**: payment scheme simulation, failure modes, async settlement, reconciliation ## What gobank-products would need to change To integrate with mock-fps, gobank-products would need to: 1. Accept a payment outcome event (success/failure) rather than recording movements directly in `DepositAcceptance` / `WithdrawalProcessing` 2. Model a `PendingPayment` state between initiation and settlement 3. Handle payment reversals This is not urgent — the current synchronous model is correct for simulation and testing. This issue tracks the eventual integration point. --- *Migrated from Codeberg: originally [#1](https://codeberg.org/hum3/mock-fps/issues/1), opened 2026-03-17.*

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

hum3/mock-fps#1

No description provided.

Rows
Columns