MENA payment processing case study
Hydracode Gateway
Checkout optimisation for high-risk merchants in MENA: improving deposit conversion by connecting checkout UX, localized instructions, payment analytics, and data-driven orchestration logic.
Deposit checkout
Pay 500 AED
14:58 left
Local bank
Cards
Wallet
PSP A
67%
67%
PSP B
78%
78%
PSP C
timeout
timeout
Started
Initiated
Successful
North Star
Successful deposit conversion rate
The project moved the discussion from “provider conversion is bad” to a measurable payment funnel: created attempts, checkout actions, method behaviour, PSP status, routing quality, and final deposit outcome.
Successful deposits divided by created deposit attempts.
Fewer users left the checkout without taking the next payment action.
Better provider monitoring and degraded-route handling reduced unresolved states.
Clearer instructions and pending/failed states reduced avoidable support load.
Situation
Fragmented payment behaviour across MENA
Different countries had different preferred methods, bank restrictions, PSP stability, user trust patterns, and drop-off reasons. The system needed to separate UX friction from real bank or provider failures.
Merchant problem
Deposit conversion in MENA was unstable and below target, especially on local methods and card payments routed through alternative providers.
- Merchants could not see where exactly users were lost in the payment funnel.
- Declines, cancellations, pending states, and timeouts were mixed into one broad conversion issue.
- Routing accounted for technical availability but not enough for user friction and fail reasons.
User problem
Checkout pages often failed to explain the next action clearly enough for local payment behaviour and manual or redirect-based flows.
- Users did not always understand whether they were still with the merchant or already with a provider.
- Manual and bank-transfer flows lacked enough localized step-by-step instruction.
- Pending and failed states did not offer clear recovery paths.
Process
From technical status to user state
The checkout was reframed around what the user sees, understands, and can recover from, while still preserving the processing logic behind the scene.
01
Land on checkoutConfirm amount, currency, merchant, method, and time limit.
02
Understand actionShow clear localized instructions for the selected payment method.
03
Perform paymentCard input, bank redirect, copied details, deep link, or wallet flow.
04
Track interactionMeasure copy actions, “I paid”, “I can’t pay”, retries, and method switches.
05
Recover clearlyExplain pending, failed, expired, or provider-unavailable states with next actions.
Discovery layers
The problem was decomposed into four operational layers before changes were scoped.
- User Experience: clarity, trust, instructions, errors, retry, and alternative method choice.
- Payment Method: cards, bank transfer, redirects, wallets, vouchers, and manual confirmation.
- Provider / PSP: approve ratio, timeouts, pending duration, latency, callbacks, and final statuses.
- Orchestration: country, currency, method, amount, merchant, availability, limits, and failover.
Checkout UX decisions
Each screen was redesigned to reduce ambiguity before users reached a fragile payment step.
- First screen: merchant, amount, currency, method, expiration timer, trust label, and primary CTA.
- Instructions: short inline help, step-by-step guidance, and error-prevention copy.
- Manual flows: copy recipient, amount, reference, “I have paid”, and “I can’t pay” were tracked separately.
- Status screens: pending and failure states explained what happened and what to do next.
Checkout design
Product changes users could understand
Trust-first payment context
Show merchant, amount, currency, selected method, expiration timer, and a short instruction before the user commits.
Localized instructions
Adapt checkout guidance to local MENA payment behaviour, not just translated interface strings.
Manual payment clarity
Track copied details and confirmation actions so the product can identify where users get stuck.
Pending state explanation
Replace technical pending screens with expected timing, refresh, support, and alternative-method guidance.
Actionable failures
Separate insufficient funds, expired payments, provider unavailability, and unknown errors with distinct recovery copy.
Retry as recovery
Use retry and alternative method suggestions only where the reason indicates that recovery can actually help.
Orchestration
Routing based on conversion signals
Routing moved from a static country-currency-method map to a broader decision model that considered historical success, current degradation, completion speed, amount ranges, merchant risk profile, and user retry behaviour.
Before
Country + currency + method -> fixed provider route.
After
Payment route selected from product, technical, and behavioural signals.
Country
Currency
Method
Amount range
Merchant
Provider availability
Success rate
Decline mix
Timeout rate
Completion time
Risk limits
Failover logic
Failover was treated as a controlled recovery mechanism, not blind retry.
- Technical error from provider A: route to provider B.
- Bank decline: show actionable user message instead of automatic cascade.
- SLA timeout: mark route as degraded and reduce traffic share.
- User retry after decline: suggest a method with higher success probability.
Routing criteria
Provider priority was tuned by conversion quality, not availability alone.
- Provider success rate and method success rate by country and currency.
- Timeout rate, average completion time, and current provider latency.
- Decline reason distribution to separate bank problems from UX problems.
- Merchant segment and risk profile constraints.
Analytics
Checkout events for funnel transparency
Event analytics made it possible to understand whether the user failed because of UX friction, method complexity, provider behaviour, bank decline, timeout, or a weak recovery path.
Core events
Events were added across checkout entry, method choice, instructions, payment action, status, retry, and return to merchant.
checkout_opened
payment_method_selected
payment_instruction_opened
payment_details_copied
payment_started
i_have_paid_clicked
i_cannot_pay_clicked
payment_status_success
payment_status_decline
payment_retry_clicked
alternative_method_selected
Event properties
Properties connected user actions to merchant, provider, route, device, status, and time-based funnel measurements.
- merchant_id, shop_id, transaction_id, country, currency, amount.
- payment_method, provider_id, route_id, checkout_type, language, device_type.
- status, decline_reason, is_retry, is_cascade.
- time_from_checkout_open, time_to_payment_start, time_to_final_status.
Results
Conversion improved through UX and routing together
The largest gain came from treating payment conversion as a combined product system: checkout clarity, localized behaviour, provider reliability, and orchestration quality.
Business impact
Depending on country and payment method, deposit conversion improved by 12-18%. Checkout drop-off decreased by 20%, and payment-related support tickets decreased by 15-25%.
- Merchants received a more transparent payment funnel, not just final statuses.
- Checkout copy and states became more useful for user recovery.
- Routing decisions became sensitive to success rate, speed, fail reasons, and timeouts.
- Manual and bank-transfer flows became measurable at the user-action level.
Metric snapshot
| Metric | Before | After | Change |
|---|---|---|---|
| Deposit conversion | 68% | 78% | +10 p.p. |
| Checkout drop-off | 24% | 19% | -20% |
| Payment cancel rate | 11% | 8% | -27% |
| Timeout rate | 7% | 4.5% | -36% |
| Completion time | 3m20s | 2m25s | -28% |
| Retry success | 18% | 29% | +11 p.p. |