Cybersecurity for UAE Retail Payment Systems

A Dubai retailer sells through shops and an online store. At the counter, an employee handles a card terminal and a till. Online, the website sends buyers to a payment provider and receives a confirmation when they pay. One evening the till stops receiving confirmations, and an employee suggests taking card details by phone to finish the orders. That workaround would create a new path for sensitive data at the moment the business has the least time to control it.

Start with how customers pay, how the retailer learns the result and what staff do when the normal path fails. Reduce the places where account data can enter or remain in the business. Then protect the systems and people that can change checkout, issue refunds and determine whether an order is paid. Confirm the applicable responsibilities with the acquiring bank or payment provider and verify them through an actual exercise.

Map the payment path and the people who control it

Follow one transaction through each channel. At the shop, identify the terminal, till, network and acquiring service. Online, follow the browser from the merchant page to the payment form and trace the status back to the order system. Add receipts, transaction logs, support tickets and finance exports. Write down what each part receives and which identifiers it needs to perform its job. Ask where a full card number or security code could accidentally appear, including in screenshots, customer messages and troubleshooting tools.

Name the parties that operate the service and handle an incident. A retailer may buy an e-commerce platform, use a separate payment gateway and have an acquiring relationship with a bank. The Central Bank of the UAE describes merchant acquiring among the activities addressed by its Retail Payment Services and Card Schemes Regulation. That regulatory context helps identify the parties in a proposal. The retailer should separately establish the duties that apply to its own role, setup and agreement. CBUAE on the Retail Payment Services and Card Schemes Regulation

Reduce the card data the business handles

Ask the acquiring bank or payment provider which terminal and checkout configuration it supports. PCI Security Standards Council describes point-to-point encryption as cryptographically protecting account data from the point of acceptance to a secure decryption point. If a supplier proposes a validated solution, confirm the exact listing and that the equipment, installation and operating procedures match it. Check the remaining merchant responsibilities and validation approach with the acquiring partner. A product name or an encryption claim alone does not establish the merchant's scope. PCI SSC on point-to-point encryption

Keep an inventory of the actual terminals. Record their location and identifiers, who is authorized to replace them and where staff can verify a service visit. Train employees to check for unexpected attachments, changed cables or a device that does not match the inventory. If a terminal looks wrong, take it out of customer use under the agreed procedure and contact the provider through a trusted route. Keep a dated inspection record and check the replacement before it takes payments.

For online orders, ask whether the merchant's systems need to receive card information at all. A hosted checkout may let the retailer work with a transaction reference or token. Determine exactly what the token can do, who can use it and whether sensitive information could still enter a merchant system through a secondary flow. Staff should have an approved way to redirect a customer who tries to send card details in a message. Use the payment service's approved method for recurring billing or telephone orders if those channels are in scope.

Protect checkout and verify payment confirmations

Inventory the people and services that can change the store, checkout links, tags, plugins and payment settings. Limit access and require approval for material changes. If a marketing tool can add code to the page a customer sees before paying, treat it as part of the security discussion. Review what a browser loads and how the business would notice if the destination or behavior changed. Test on the public site with approved test methods after an update.

PCI SSC publishes guidance on payment page security and preventing e-skimming, including guidance for requirements 6.4.3 and 11.6.1. These address controls concerning payment page scripts and detection of unauthorized changes, where applicable. Ask the acquiring partner which validation approach and requirements apply to the exact integration. Keep the evidence for the configuration you use, including what the provider supplies and what remains under the retailer's control. PCI SSC on payment page security and e-skimming

Careem UAE's historical QR payment post illustrates how a payment interaction looks to a customer. The retailer needs separate evidence for the steps behind its own checkout, including who controls a link or code and how its system confirms the outcome. A screenshot from a customer may be useful for support, while the order record should rely on the approved source of payment status.

Have the application owner show how the payment provider's confirmation is verified. The store should match the provider transaction to the intended order, amount and currency before releasing goods. Ask what happens when a notification arrives twice or out of order. Test a delayed success after the browser times out and a refund that is still pending. Keep statuses distinct so an employee can tell whether the payment failed, is awaiting confirmation or has already been captured.

Test what happens when a checkout configuration changes. A new storefront theme, a payment plugin update or a revised redirect may move a responsibility between suppliers. Have the release owner compare the actual checkout with the last approved version and show where the payment provider receives the customer. Inspect whether logs or analytics captured values that were meant to stay inside the payment flow. Keep a short rollback procedure for the checkout change and give the duty manager an approved option to suspend it if the destination or behavior cannot be verified.

Make refunds and exceptions visible

Limit who can initiate and approve refunds. Tie the refund to the original order and transaction using the approved process. Give supervisors a view of repeated refunds, large adjustments or attempts to override the normal path. Decide which events require an independent review and test whether the system actually enforces it. A well-protected payment page does little to help if a stolen store login can issue credits without review.

Compare finance records with the payment provider's settlement and refund data. Choose a reconciliation period and assign a person to investigate differences. Match identifiers and amounts, then check fees and timing separately. A difference may arise because a payment has not settled yet or because an order was marked paid incorrectly. Give unresolved items a status, an owner and a date for the next check. Include a disputed payment in the rehearsal and confirm which records the retailer can provide without collecting more card information from the customer.

Practice a checkout outage without inventing a new payment channel

Agree the fallback with the acquiring partner and store managers before a busy day. If the terminal is unavailable, staff need to know which alternate device, channel or deferred process is approved. If the website cannot verify payment, staff should be able to hold the order and check the provider's status before asking the buyer to retry. Do not let improvised notes, email or chat become a way to collect card details.

Consider a hypothetical evening when 80 checkout attempts time out at the retailer. The provider later confirms 30 payments, marks 40 as failed and still shows ten as pending. If employees ask all 80 customers to pay again, the 30 confirmed cases face a potential second charge and the ten pending cases remain uncertain. Instead, reconcile the provider's records with the orders, keep the pending cases visible and follow the approved retry procedure for the failed transactions. The numbers illustrate the reconciliation problem, rather than an observed incident.

Run the exercise with staff who work the relevant shift. Confirm that they can reach payment support, look up a transaction with ordinary permissions and explain what the customer should do next. Include a case where the store receives confirmation after the customer leaves. Agree how staff will contact the customer and close the order without disclosing payment details through an unapproved channel.

Make pending payments visible at shift handover. The incoming supervisor needs the order references, what has been checked and which cases still need a provider response. Record whether goods were handed over or held. If the payment appears in the next settlement file, the finance team should be able to connect it to the original case without searching through customer messages. Review the fallback after the exercise and remove steps that require staff to copy sensitive details into a general-purpose tool.

Prepare for suspected exposure and review the controls

Keep a short response plan for a terminal concern, unexpected checkout change, suspicious refunds or possible exposure of card details. Name who can suspend the affected function, who contacts the acquirer or payment provider and who leads the retailer's investigation. Preserve the relevant records, such as device identifiers, deployment changes and transaction references, through the approved process. Ask the acquirer what it needs, and have the responsible legal or privacy lead assess applicable notifications separately.

Keep the acquiring support contact available even if the store portal is unavailable. Check the service after changes to the site, terminal fleet or acquiring agreement. Test a successful sale, duplicate notification, failed payment and refund. Verify access for current staff and remove old accounts. Compare the test evidence with the contract and the documented payment map. Where a supplier assumes responsibility for part of the service, confirm how the retailer can verify that the work has been done.

For the Dubai retailer, useful acceptance criteria could include a verified terminal inventory, a controlled list of people who can change checkout, authenticated payment confirmation and a documented way to reconcile an outage. The manager should know which exceptions require a provider and which can be handled in the shop. Those checks connect payment security to the ordinary work of taking money, fulfilling orders and explaining the result to customers.