What The ENTERTAINER’s Payment Switch Can Teach UAE Merchants

David Ashford, then chief information officer at The ENTERTAINER, told Checkout.com that the Dubai merchant saw a 16% increase in online revenue after switching from its previous payment provider. In the provider’s published case study, the problem was that some customers who tried to buy were being declined. The case attributed the friction to address verification and the handling of restrictions on newly issued cards. It gives no comparison period, attempt counts or breakdown of the revenue change. The 16% is a historical result reported in a vendor case study, with a merchant executive’s account. A retailer weighing a switch today needs its own way to find the lost orders and measure whether a new route recovers them. Checkout.com’s case study with David Ashford

For The ENTERTAINER, a successful checkout has a visible consequence beyond the payment. The merchant’s customer guidance directs people to purchase a membership, with the website and app providing information about available options. The customer buys access that the merchant then needs to make available. That makes the case useful to other Dubai and UAE businesses selling memberships, passes or digital products. During a provider change, the payment has to succeed, the account has to reflect the purchase, and finance has to match the money to the order. The ENTERTAINER’s membership guidance

The ENTERTAINER UAE’s March 2026 Instagram reel presents its later One Heart membership campaign. It gives context for the merchant’s membership product. The campaign was separate from the historical provider switch and offered complimentary access.

Find the step where the order was lost

Start with a failed order the customer support team can trace. Did the shopper leave before sending a payment request? Did the request fail a check in the merchant’s integration or at the provider? Was a card payment declined after submission? Did the customer complete authentication and return to the merchant’s site? Different teams may own each step. If a store reports all those events as payment failures, a provider comparison can point to the wrong part of the journey.

Take a hypothetical Dubai membership seller. Its support inbox has several messages from people who saw a bank notification and still cannot open the product. The seller can start by matching the account, internal order and provider payment reference. If the provider records authorisation but capture is still pending, the seller needs to inspect what its checkout is waiting for. If payment was captured and the membership stayed locked, inspect the event that should have triggered activation. The customer experiences a failed purchase in either case. The fix depends on the state recorded by each system.

Use the historical account of address and card restrictions as a prompt to inspect data and flows. The appropriate action depends on the provider, transaction and merchant setup. A team can ask each provider to explain which fields it sends, which response it received and what the customer should do next. Keep the question narrow enough to test. For example, when a payment stops after the customer returns from verification, compare what the browser shows with the status the merchant’s backend received. That can distinguish an integration defect from a payment decision. Checkout.com’s current documentation distinguishes authorisation, capture, refund and settlement stages. Checkout.com payment status documentation

Build a comparison the merchant can repeat

Choose a denominator before looking at the results. A provider can report approvals as a share of authorisation requests. The merchant can measure completed purchases as a share of checkout sessions that reached the payment step. Both are useful. They answer different questions, particularly when a shopper tries again or changes payment method. Keep a link between attempts and the underlying order so a single purchase does not inflate the recovered-order count.

For an illustrative UAE merchant, suppose 900 of 1,000 comparable payment-stage checkout sessions reached a paid order on the original route. A later group records 925 paid orders from 1,000 sessions. That is 25 more completed orders and a rise from 90% to 92.5%, or 2.5 percentage points. It does not establish the change in net revenue. Check order values, refunds and the cost to process the payments. It also matters whether both groups bought similar products under similar conditions. A promotion may bring shoppers with different devices or payment preferences and shift the result independently of the provider.

If feasible, define a limited group of orders to send through the new route and leave a comparable group on the existing one during the same period. If the business has to compare one period with another, record promotions, product changes and operational incidents so a later reader can see what else changed. Break results down by device, payment method and the types of issuer or card the business can identify appropriately. Smaller groups may have too little data to judge. Look at counts alongside rates before changing the route for more customers.

Measure what happened after approval. A higher approval rate can coexist with more manual work, customer confusion or refunded purchases. Track orders that were charged once, activated as intended and visible in finance. Compare the cost to serve exceptions as well as fees on successful payments. Those measures make a useful counterweight to a headline percentage, especially when someone wants to move all traffic after the first strong day.

Test the change with support and finance in the room

Put an owner beside each event in the new checkout. Engineering can show what happens when a payment response is delayed, duplicated or received after a customer closes the app. Product can verify which message the customer sees while a payment is pending. Support can locate the order and explain the next step. Finance can trace the capture or refund through a report and, later, to the bank. If one team can finish its test only by asking an engineer to look at a raw log, record that dependency before expanding.

A common scenario to rehearse is an uncertain response. Imagine the customer presses pay and the browser times out. The merchant needs a way to find out whether that order already has a payment in progress before it lets the person try again. A switch between providers adds another possible route for a second charge. Have the team show how an order remains linked to its original attempt and how it decides when a retry is safe. Test the case where the original response comes in after a retry was offered.

In a digital membership business, include the opposite failure. The customer gets access before the payment reaches the merchant’s agreed success state. Test whether support can identify that state and whether finance can distinguish a genuine unpaid order from an event that simply arrived late. Agree what should happen to access if a payment is refunded or reversed. The right response depends on the merchant’s product and terms. The operational test is that support, finance and the account screen can explain the same result.

Keep a route for old transactions

When a merchant moves new transactions, older purchases can still need refunds, dispute handling or reconciliation. Keep the original provider reference on those orders and give staff access to the records they need. Ask each provider what remains available after termination or during a wind-down, including how long reports can be retrieved and how open cases are handled. Have a named person test access before the team depends on it.

Saved credentials need a separate decision for any business that uses them. Ask both providers what can transfer through their supported migration process and how the business can validate the result. If some customers will need to provide payment details again, plan the communication and record how many people can continue without interruption. The ENTERTAINER case does not describe a credential migration. Its current customer materials describe membership purchases, so the case should be read as an example of checkout acceptance rather than evidence about recurring payment transfers.

On the finance side, start with a known set of captures, fees and refunds. Match their provider identifiers to an expected payout and compare the bank entry. Checkout.com’s current support material describes a settlement statement and a transaction breakdown, and explains how its payout identifier helps match settlement to the bank account. Ask the prospective provider to show the equivalent records for the merchant’s own configuration. A clean demonstration using one payment should be followed by an example with a refund or adjustment. Checkout.com settlement report guidance · Checkout.com bank reconciliation guidance

Decide what warrants moving more orders

Write the expansion and rollback conditions before switching on the new route. An example of a stop condition is a confirmed duplicate charge in the pilot. Another is a gap between captured payments and activated memberships that the support team cannot resolve through its normal process. Decide who can stop new traffic and what happens to orders already in progress. Moving future purchases back to the earlier provider still leaves a set of payments on the new one that need to reach a final state.

Revisit the commercial question once both routes have been observed under comparable conditions. If the provider is recovering previously lost orders, identify which types of attempts improved and what those orders contributed after costs. If the largest improvement came from a change the merchant made to its own checkout, record that too. It may be possible to keep the better flow when a provider changes again. The record should also show which uncertainties remain, such as a payment method used too infrequently in the pilot to draw a conclusion.

Ashford’s account describes a merchant that considered declines a problem worth investigating. For the next UAE merchant, a sensible basis for moving more traffic is a traceable improvement in completed orders alongside reliable refunds, support and settlement. Keep the comparison, exception log and first payout reconciliation together. Those records let the merchant explain what changed from the customer’s first attempt through to the money reaching the bank.

The same file gives the team a baseline for the next review. If repeat contacts climb after the pilot ends, support can check whether the change is concentrated in old orders, a device group or a new payment option. If a payout is late, finance can locate the affected batch before someone changes customer-facing routing. Regular review makes the provider decision easier to revisit as the merchant’s order mix changes.