Map the movement of money before connecting
Identify who receives the payment, which order each payment identifier belongs to and how settlement will be followed. A provider’s commercial acceptance requirements are separate from technical connectivity. The software team needs to know which information and permissions are actually available rather than designing around unconfirmed assumptions.
A browser return is not final confirmation
A customer may close the browser after paying or reopen the return page several times. Order status should therefore not depend solely on visiting a page. The result needs to be checked through the provider’s authoritative process, and processing the same event again should not create another order or financial effect.
Make intermediate states manageable
An uncertain payment is not the same as a failed one. Responses can arrive late and a connection can fail during confirmation. The design should preserve these states and define rechecking or support investigation. Interface wording needs to describe the actual state without encouraging duplicate payment or premature conclusions.
Include reconciliation in delivery
After launch, finance teams need a way to compare orders, transactions and settlement information. Discrepancies need identifiers, states and an owner. Payment integration becomes manageable when the customer sees a clear result and the organisation can account for transactions, not merely when one test payment has succeeded.