An AI assistant receives a simple instruction: “Pay the approved supplier invoice.”
It identifies the invoice, generates valid JSON, and calls an authenticated tool. Yet the backend still needs to establish whether the customer authorized this exact payment, whether the beneficiary details remain valid, and whether another worker has already submitted it.
These questions belong to the execution architecture.
The Problem
Authentication establishes who is calling. Business authorization determines which financial action that caller may perform.
A workload credential does not, by itself, establish permission to debit a customer’s account. Similarly, a confirmation screen provides limited assurance if the amount or beneficiary can change between approval and execution.
The architectural boundary is straightforward: the model proposes an action, while trusted application code controls its admission and submission.
Where It Gets Difficult
Approval must identify the exact operation
Bind approval to a backend-created payment intent containing the relevant account, beneficiary version, amount, currency, fees, and expiration.
Include the intent identifier and revision so that approval cannot simply be copied onto another payment. Changes to approved details should invalidate the previous approval.
Concurrent workers can consume the same authority
Checking permission and later writing a queue message leaves a timing gap.
Within the application’s consistency boundary, coordinate approval consumption, state transitions, invoice reservations, limit reservations, and durable dispatch preparation.
Locking one intent does not automatically protect an account-wide allowance or prevent a separate intent from paying the same invoice.
A timeout leaves an uncertain outcome
A bank may receive a request even when the execution worker never receives its response.
Creating a replacement payment can therefore introduce a duplicate. Preserve the existing intent and resolve its status through supported lookup, authenticated callbacks, or reconciliation.
Provider idempotency behavior must be checked against the specific endpoint, API version, and retention window.
Architectural Direction
Separate policy management from runtime enforcement.
The control plane manages permitted operations, delegation rules, approval thresholds, policy versions, and emergency restrictions. The execution layer gathers trusted context, evaluates each intent, records the admission decision, and invokes a constrained payment adapter.
A practical implementation should:
- Resolve invoice, beneficiary, and delegation details from authoritative backend records.
- Keep provider credentials within the execution environment.
- Bind approval to an exact, versioned intent.
- Coordinate local admission changes with an outbox record.
- Handle repeated delivery and uncertain provider outcomes explicitly.
These responsibilities can initially live in one backend application. Separate services should follow operational needs.
A Short Example
A customer approves a ₹48,000 supplier payment on Android. The backend reserves the invoice amount and applicable allowance, then prepares durable dispatch.
The bank response times out.
The application displays “Payment status pending confirmation” and retrieves the same intent when reopened. A later authenticated bank event confirms acceptance, and the backend continues tracking the payment according to the rail’s status model.
The conversation can resume without creating a fresh payment.
The Takeaway
An authorization decision and a payment outcome are separate records.
Governed AI execution needs explicit authority, transaction-bound approval, coordinated admission, and a recovery path for uncertainty. The mobile application and the assistant should explain the backend’s recorded state.
For the admission pseudocode, revocation trade-offs, audit considerations, and full architectural reasoning, read the full article on Medium.
Top comments (1)
Splitting the authorization decision from the payment outcome is the line that separates working systems from demos. The timeout section is where most teams learn it: treating 'no response' as 'failed' is how duplicate payments get born, and the fix is always the same boring one, resolve the original intent before anyone proposes a replacement. Binding approval to the beneficiary version is a nice detail too, because 'correct at approval time' and 'correct at execution time' drift faster than people expect.