Payment Fallback Architecture: One Obligation Across Every Path

1. Map every path to the same obligation

Northline assigns the payable a durable obligation reference, O-0421. The ERP invoice, provider operations, portal instruction and recovery job retain their own identifiers. Each must map back to that obligation.

A shared invoice label helps connect records. Coverage also requires the mapping to affect release.

Matching the supplier and amount alone is insufficient. A supplier may have several invoices for USD 10,000. The obligation owner must resolve which payable each instruction can satisfy and retain that mapping across systems, handoffs and restarts.

The path map must also identify the moment each instruction becomes executable. A portal “draft” may be harmless in one workflow; saving or uploading an instruction may schedule payment in another. Northline must establish its portal’s actual behavior before treating final approval as the last hold point.

A recovery job needs the same distinction. Repeating A under a verified provider contract remains the original operation. Creating a new operation requires another attempt record against O-0421.

Use the manual bank-payment handoff guide to assign these responsibilities between AP, Treasury, the provider liaison and the release approver.

2. Keep completed payments and executable attempts within one limit

O-0421 has USD 10,000 of authorized capacity.

The shared control accounts for both completed payment effects and reserved amounts for attempts that can still take effect:

Completed amount + reserved amount ≤ authorized amount

A reservation is a claim against the obligation’s payment authority. It is separate from the bank account balance.

A must acquire that claim before its instruction can become executable. When the response disappears, the claim remains. UNKNOWN means the company has not established whether A paid or could still pay.

Northline’s intended recovery branch looks like this:

In the UNKNOWN row, A may already have paid. Its reservation conservatively accounts for that unresolved exposure. When payment is confirmed, accounting moves the amount from reserved to completed without counting the same attempt twice.

If A is confirmed paid in full instead of closed without effect, the obligation is satisfied. Another full payment is refused.

Completed payment does not restore available authority. Neither does an elapsed timer, a worker crash or an operator marking a job failed. Releasing a claim requires evidence that the attempt cannot produce an unaccounted payment effect.

The existing execution-boundary diagram shows the critical moment: A is UNKNOWN, USD 10,000 remains reserved, and a new full-payment fallback stays on HOLD.

3. Keep competing payment paths within one limit

Suppose Northline establishes that A did not pay and cannot pay later. Section 4 explains the required evidence.

AP’s replacement B and Treasury’s portal instruction C are both ready for USD 10,000. The buyer needs one outcome across those paths: only one eligible instruction can proceed.

If B proceeds, C stays on HOLD. An unavailable decision, lost reply or restart does not give either team another right to pay. Each team retains its original request and follows the agreed recovery procedure.

Ask the payment owner to demonstrate that result across the declared paths, including the portal. Review the supported environment, evidence and exclusions before accepting the workflow.

Provider idempotency remains useful. Stripe and Adyen document protection for repeated requests within their applicable contracts. Those protections do not, by themselves, connect an independent provider request to a bank-portal payment.

For that distinction, see idempotency across providers.

4. Resolve UNKNOWN with evidence that also closes later execution

To release A’s reservation, Northline needs to establish both conditions:

1. A did not produce the payment effect.
2. A cannot produce that effect later.

A timeout proves neither. A cancellation request may still be pending. An empty statement search may precede settlement. Stopping W may leave an instruction already accepted by a provider or bank.

The evidence must identify A and the relevant obligation, come from an authoritative source for the route, and be interpreted under that route’s status and finality rules. Conflicting records remain an open question.

Northline must also establish what happened to queued work, delayed submissions and old executors. A final provider outcome cannot close an independently executable local submission that has not yet reached that provider. Both the external operation and the remaining means of dispatch matter.

A local “failed” label is therefore insufficient on its own. A payment that occurred and was later returned also needs its own accounting and authority rules; it cannot simply be classified as never having occurred.

The existing evidence-state model has three branches:

Evidence branches adapted from HALTSEAL’s Architecture diagram. This is an explanatory full-payment model.

For this case, assume matched, authoritative records establish that A never paid and cannot execute later, and that Northline has excluded any remaining submission of A. Its claim can then be released.

That restores eligibility for a replacement. The replacement still needs a fresh decision.

This rule concerns a separate payment. A protected retry of the same operation follows the provider’s verified retry contract. Stripe’s error-handling documentation, for example, distinguishes network retries from indeterminate server errors and warns that an earlier operation may have produced side effects.

Use the timeout and safe-retry guide to match the proposed action to the evidence available.

5. Approve the payment that will actually be sent

B is eligible for review. That does not yet mean the payment has been sent or settled.

The payment owner needs to confirm:

• The intended payment: the obligation, beneficiary and destination, USD 10,000, currency, funding account and route match the approved instruction.
• Current approval: the authorization remains valid, including relevant changes, expiry and revocation.
• The outcome of A: authoritative evidence permits this replacement, with no unresolved original exposure.
• Path coverage: the actual provider or portal release follows the reviewed decision.

A changed beneficiary needs appropriate approval. An earlier ACCEPT is not permission to send a different instruction or create a second full payment.

Keep a reviewable record of the approved instruction, decision, supporting evidence and subsequent outcome. Agree who will investigate if the outcome is uncertain.

If B’s dispatch becomes uncertain, C stays on HOLD while B could still pay. Recover the exact original B before considering another replacement.

6. Find bypasses and make recovery usable

Northline’s review reveals a portal role that can release payments without the shared claim. It also finds a bulk-file upload procedure outside the platform’s normal release checks.

Those are independently executable paths. A platform notification cannot stop them after dispatch.

Northline must bring each path under an effective shared release control, restrict its ability to pay this obligation, or retain it as an explicit coverage gap. A documented procedure needs evidence that it coordinates competing releases in practice. Drawing the portal inside an architecture diagram does not establish enforcement.

Inventory normal, emergency and recovery use with the people who operate them. Include bank accounts, portal roles, file uploads, scheduled jobs and override procedures. Revisit the inventory when those change.

Recovery also needs an accountable owner and a next review time. The owner should know which attempt holds capacity, what evidence is missing, who can obtain it and what will allow valid work to resume.

Once these boundary conditions are established, Northline can follow the intended recovery branch: A closes without effect, B acquires the claim, B passes fresh release review and B pays. C is then refused as another full payment against a satisfied obligation. The recovered workflow must prevent W from reviving A or creating another payment outside the shared control.

A failed or interrupted process does not prove that payment exposure disappeared. Keep the affected payment on HOLD until authoritative outcome evidence and the agreed recovery procedure permit the next action.

The coverage worksheet turns these questions into a path map with owners, hold points, evidence gaps and follow-up dates.

Read the existing Lab reports with their scope attached

The public Payment Control Lab provides three useful comparisons:

These v0.2.0 fixtures use a separate synthetic USD 1,250 obligation. They illustrate the findings relevant to Northline; they are not executions of this company case or tests of its concurrent reservations and final-release integration.

The Lab reviews supplied records. Declared route coverage, obligation mappings and evidence labels are operator assertions. It does not authenticate bank evidence, discover omitted paths or execute, block, sign or authorize a payment.

Each report includes an owner summary and supporting records. Use the developer preview to inspect them together. For a subsequent observational evaluation, the Shadow guide explains how to compare decisions using the information available at decision time. Shadow ACCEPT grants no reservation or dispatch authority.