Offer and confirmation
Show the service, currency, amount, material conditions, customer identity needs, and final confirmation without hidden selections or ambiguous totals.
Transaction route / provider-aware
Design the whole Jordan transaction, including what happens when it does not finish cleanly.
Jordan's regulated retail rails are important context, but the build begins with the merchant's actual provider, contract, credentials, settlement model, and customer-support process.
Working checkpoints
A payment button is one moment in a longer operating journey.
Keep commercial promises, provider events, invoice or receipt work, fulfillment, and accounting evidence connected without pretending they are the same system.Provider boundary
Store a local transaction record before redirect or submission; verify signed callbacks; make duplicate, late, missing, and out-of-order events safe.
Receipt and fulfillment
Tie the accepted provider state to the correct receipt, service action, notification, and staff queue rather than trusting a browser success screen.
Refund and reconciliation
Give staff an exception queue with provider references, internal references, timestamps, amounts, owner, notes, and a daily comparison path.
Route
Test the paths customers usually discover first.
- 01
Choose the provider
The Jordan operator confirms the licensed or authorized relationship, supported methods, settlement, API terms, fees, and support contacts.
- 02
Model every state
Write pending, authorized, paid, failed, cancelled, expired, reversed, refunded, disputed, and unknown behavior before coding.
- 03
Exercise failure
Test timeouts, retries, duplicate taps, closed browsers, delayed callbacks, mismatched amounts, provider downtime, and staff correction.
- 04
Reconcile with evidence
Prove that provider records, internal orders, receipts, fulfillment, refunds, and accounting handoff can be compared without guesswork.
No payment-provider relationship is implied.