A conversion instruction may fail or expire before the provider can complete it. Automatically trying again can be convenient, but it may also execute on different terms from those the customer accepted. Its eventual design should make the boundary between authorised retry and a new commercial decision explicit.
Preserve the accepted instruction
The conversion record should identify the amount, supported destination balance, charges, validity and any agreed execution tolerance. An indicative estimate should remain distinguishable from an executable quote. If the provider cannot complete the accepted instruction, the system needs an accurate status rather than a success message based on submission. The customer should know whether value remains in token form, is reserved for conversion or has reached the card-account stage. These states affect what the programme may attempt next. A clear record also prevents support teams from reconstructing the original promise from a later screen showing a different market estimate.
Follow a failed execution
Imagine a hypothetical quote accepted just before the execution provider becomes unavailable. When service returns, the earlier terms may no longer be supported. The programme should follow the rule agreed at acceptance: abandon, seek fresh approval or retry within a clearly defined limit if authorised.
It should not silently enlarge the tolerance to force completion. If an attempted order's outcome is uncertain, the original reference must be checked before another order is placed. Otherwise, a retry intended to recover one failure can produce two completed conversions and create a new reconciliation problem for the customer.
Explain tolerance in customer terms
If the product allows a range of outcomes, it should show the practical effect on the net balance rather than only a technical percentage. The customer needs to understand the minimum acceptable result, relevant charges and when the instruction expires. The provider agreement must support the same rules. A limit displayed in the interface has little value if the execution system applies another calculation. Testing should cover values just inside and outside the permitted range, partial responses and an expired instruction. The operation should preserve the customer's choice even when the easiest technical response would be to keep retrying.
Reconcile the completed result
After execution, the receipt should compare the authorised instruction with the actual outcome, explaining any permitted difference. Failed attempts and charges, where applicable, should remain traceable. ALFA's whitepaper promises no fixed redemption value, guaranteed liquidity or conversion price. A future service should therefore make execution conditions visible without suggesting that its retry policy eliminates market or provider risk. The commercial objective is narrower and achievable: one understood instruction, one accountable outcome and a clear request for a new decision when the original permission no longer supports the transaction the system could perform.
