A delayed bank-transfer payment should be represented as initiated or pending until settlement is confirmed. The expected credit amount may be displayed separately, but it should not be included in the customer’s available or spendable credit balance until the platform’s documented settlement condition has been met.
This distinction prevents a transfer instruction from being mistaken for received funds. It also gives product, finance, and operations teams a clearer basis for handling delays, failures, duplicate notifications, reconciliation issues, and reversals. Exact state definitions and accounting treatment will depend on the payment provider, business model, jurisdiction, and internal policy.
The Short Answer: Show the Transfer as Pending and Keep Its Credits Unavailable
Before settlement, the interface should communicate three facts clearly:
- The bank transfer has been initiated or detected but is not yet settled.
- A corresponding amount of credits is expected if settlement succeeds.
- Those credits are not currently available to spend.
Avoid labels such as paid, cleared, settled, or completed merely because the customer submitted a transfer instruction. Initiation confirms that a process has started; it does not necessarily confirm that funds have been received and made final under the relevant settlement policy.
A clear customer-facing presentation might look like this:
Bank transfer status: Pending
Transfer amount: $10,000
Expected credits: 10,000 credits
Available credits from this transfer: 0 credits
Initiated: September 20, 2026 at 10:15 UTC
Reference ID: BT-8F42K1
Estimated availability: September 22–23, 2026, subject to settlement
These figures are illustrative. In a real implementation, currency conversion, fees, credit ratios, settlement windows, and applicable limits may affect the eventual credit amount.
An estimated availability date should only be displayed when it is supported by reliable provider data. It should remain visibly qualified as an estimate, not a promise. If reliable timing data is unavailable, a neutral message such as “Credits will become available after settlement is confirmed” is preferable to an unsupported date.
The design should also avoid adding expected credits to a headline balance and then disabling them only at checkout. That approach can make the balance appear larger than the amount the customer can actually use. Showing pending and available amounts separately provides a more accurate representation throughout the experience.
Separate the Payment Record, Expected Credits, and Available Balance
A delayed transfer affects several related concepts, but those concepts should not be collapsed into one status or balance field. A practical design separates the payment record, the expected credit calculation, and the spendable balance.
Payment status
The payment record describes what has happened to the transfer. Useful fields may include:
- Current state, such as initiated, pending, settled, failed, or reversed
- Transfer amount and currency
- Initiation timestamp
- Provider or bank reference identifier
- Last status update
- Settlement confirmation identifier, when available
- Estimated settlement date, if reliably supported
- Failure, cancellation, or reversal reason where appropriate
The payment state should be driven by defined events rather than assumptions based solely on elapsed time. A transfer that has passed its estimated arrival date is not necessarily settled, just as a recently initiated transfer is not necessarily destined to succeed.
Expected credit amount
Expected credits represent the value that may become available after the settlement condition is met. This amount can help customers understand the intended outcome without presenting it as spendable value.
For example, a wallet view might show:
- Available credits: 24,500
- Pending credits: 10,000
- Projected total after settlement: 34,500
“Projected total after settlement” must remain distinguishable from the current available balance. If fees, exchange rates, or other adjustments can change the final amount, the interface should explain that the pending figure is provisional.
The implementation should also decide whether a change to the expected amount updates the existing pending record or creates an auditable adjustment event. The choice depends on the ledger model, but the history should preserve enough information to explain how the final credit amount was determined.
Available or spendable credit balance
The available balance should include only credits that have passed the platform’s defined availability rules. A pending transfer should not increase this balance, authorize usage, or reserve resources as though payment were complete unless the business has a separate and explicitly governed credit-risk policy.
It is also important to distinguish among:
- Payment status: Whether the transfer was initiated, settled, failed, or reversed
- Accounting recognition: How and when the transaction is recorded for financial reporting
- Credit availability: When the customer is allowed to use the corresponding credits
These events may occur at different times. A provider’s settlement notification might update the payment record first, followed by a separate ledger transaction that makes credits available. Accounting entries may follow rules that differ from the product interface. Teams should not assume that one event automatically determines all three outcomes.
Model the Bank-Transfer and Credit-Availability Lifecycle
The lifecycle should make each transition explicit and prevent repeated or out-of-order notifications from creating credits more than once. The following model is illustrative; actual terminology and transition rules should be adapted to the payment provider and operating policy.
| State | Meaning | Credit treatment |
|---|---|---|
| Initiated | A transfer instruction or payment request has been created | Credits remain unavailable |
| Pending | Settlement is still outstanding or awaiting confirmation | Expected credits may be displayed separately but remain unavailable |
| Settled | The defined settlement condition has been confirmed | The system may begin the credit-posting operation |
| Credited | The corresponding ledger transaction has completed | Credits are included in the available balance |
| Failed | The transfer did not complete | Expected credits remain unavailable and should be removed or marked failed |
| Canceled | The transfer was canceled before settlement | No credits become available |
| Expired | The transfer or payment instruction passed its valid processing window | No credits become available unless a later valid settlement event is reconciled |
| Reversed | A previously settled payment was returned or reversed | Apply the platform’s defined adjustment or recovery workflow |
Initiated
The initiated state records that the customer or system started the transfer workflow. It may be appropriate to show payment instructions, the expected amount, the initiation time, and a reference ID at this stage.
Initiated should not be treated as proof of receipt. If no provider acknowledgment exists yet, the interface may use more specific language such as “Awaiting transfer” or “Transfer instructions created.”
Pending
Pending indicates that the platform is waiting for settlement confirmation or another required event. The interface should keep expected credits separate from the available balance and give the customer a clear explanation of what happens next.
If the estimated timing changes, the display can be updated without silently changing the underlying history. A delayed estimate should not automatically convert the transaction to failed unless the provider’s rules define an actual timeout or expiration event.
Settled and credited
The event that makes credits eligible for availability should be confirmed settlement under the platform’s documented policy—not merely receipt of a transfer instruction or an unverified callback.
It can be useful to keep settled and credited as separate states. Settlement describes the payment outcome, while credited confirms that the wallet or ledger update has completed. This separation supports recovery when settlement is confirmed but credit posting is temporarily interrupted.
The balance update should be atomic or otherwise consistency-preserving: the system should not expose spendable credits without recording the corresponding ledger event. If a retry occurs, the same settlement event should not generate a second credit entry.
Failed, canceled, or expired
If settlement fails, the transfer is canceled, or the instruction expires before settlement, the associated credits should remain unavailable. The user-facing record should retain the outcome and, when appropriate, provide a reason and a path to retry with a new payment.
Do not simply delete the pending transaction. Preserving its event history helps customer support, finance, and operations teams explain what occurred and reconcile provider records against internal records.
A late settlement received after an expiration state should enter an exception or reconciliation workflow rather than being ignored or credited automatically without validation. The correct action depends on the provider’s event model and the platform’s policy.
Reversed
A reversal is different from a pre-settlement failure. It occurs after a payment was previously treated as settled and may happen after some or all corresponding credits have been used.
The response should follow a defined adjustment or recovery policy. Depending on the business model, that may involve restricting further use, creating an offsetting ledger entry, opening a receivable, or initiating manual review. Directly subtracting credits without considering prior consumption, customer terms, and applicable financial treatment can create inconsistent or negative balances.
Handle duplicate and out-of-order events safely
Bank and payment-provider notifications may be retried or delivered in an unexpected order. Event processing should therefore be idempotent: processing the same provider event more than once should produce the same final result as processing it once.
Practical controls include:
- Store the provider event ID and reject or safely acknowledge duplicates.
- Define permitted state transitions rather than accepting any status update.
- Prevent a pending event from overwriting a later settled or credited state.
- Use a unique settlement or credit-posting key to prevent duplicate credits.
- Preserve timestamps for both provider occurrence and local processing.
- Route contradictory or incomplete events to reconciliation rather than guessing.
Idempotency should apply to the financial effect, not only to the inbound webhook. Even if a notification is processed twice because of a retry, the ledger must not post the corresponding credits twice.
Maintain an auditable event history and reconciliation process
Each state change should create an auditable record containing the prior state, new state, triggering event, timestamp, reference identifiers, and resulting balance effect. Corrections should generally be represented as new events or adjustment entries rather than destructive edits that erase the original history.
Reconciliation should compare internal payment and ledger records with provider settlement data. It should identify cases such as:
- A provider reports settlement but no credit entry exists.
- Credits were posted without a matching confirmed settlement.
- Amounts or currencies do not match.
- A payment is still pending after its expected processing window.
- Duplicate records refer to the same underlying transfer.
- A reversal exists without a corresponding adjustment workflow.
Operational dashboards and alerts can prioritize exceptions without changing customer balances automatically. Teams should define which discrepancies can be resolved deterministically and which require finance or operations review.
Before implementation, validate settlement triggers and notification behavior with the payment provider. Ledger presentation, accounting recognition, disclosures, and reversal treatment should also be reviewed with qualified finance or legal professionals for the relevant business model and jurisdictions. This guide provides a product and implementation pattern, not universal accounting or legal advice.
Next Step
The payment-state guidance above is separate from Token Forge Cloud’s AI infrastructure offerings. Token Forge Cloud Managed Model APIs provide an API-first path for evaluating model demand, while Token Forge Cloud Private LLM Inference supports private deployment and serving-layer optimization using capabilities such as caching, routing, batching, quantization, and GPU scheduling.
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.