Last updated: August 17, 2026
A distributor in Deira closes a AED 62,000 order on a WhatsApp voice call. The buyer is in Riyadh, wants the goods on a truck by Thursday, and reads out a corporate Visa number to get it moving. No checkout page. No card reader. No shipment either — because the finance team has nowhere to key that number in.
That gap costs Gulf B2B suppliers real revenue every week. And the fix is a piece of software most merchants already have access to and never switch on.
Here’s what you’ll walk away with: exactly what a virtual terminal is, the six steps a phone payment travels through, why MOTO transactions carry a fraud risk that online payments don’t, what your PCI scope looks like either way, and the specific things that change when you’re processing in Riyadh, Dubai, or Doha rather than London.
A virtual terminal is a card machine that lives in your browser
Strip away the marketing and it’s simple: a secure web page where an authorised member of your team types in a customer’s card details and takes a payment.
Same rails as your online checkout. Same acquirer, same card networks, same settlement. The only difference is who does the typing — your agent instead of your customer.
That makes it a card-not-present (CNP) transaction, filed by the card networks under MOTO — Mail Order / Telephone Order. The name is a fossil from the catalogue era. The use cases are anything but:
- A logistics firm invoicing a client who pays by phone at month-end
- A dental clinic in Sharjah taking a deposit before a Monday appointment
- A trade-show team closing deals on the floor with a tablet and a hotspot
- A subscription business rescuing a failed renewal before the customer churns
- A B2B supplier whose buyer’s procurement card won’t work on a self-service checkout
Roughly speaking, if money is agreed on a call and needs to move today, a virtual terminal is the shortest path between the two.
How a phone payment actually moves
Six steps, start to finish, usually under ten seconds.
1. Your agent logs in. Named user, own password, own audit trail. Shared logins are how you lose a chargeback dispute you should have won.
2. The customer reads out their details. Card number, expiry, CVV, cardholder name, billing address, postcode. The last two matter more than most teams realise — see step 4.
3. Your agent enters the amount and hits submit. Order reference and customer ID go in the same screen, so reconciliation isn’t archaeology later.
4. AVS and CVV checks run. Address Verification Service compares the billing address against the issuer’s records. CVV proves the card was physically in someone’s hand. Neither is bulletproof, but a mismatch is your single best early warning.
5. The issuer approves or declines. The authorisation request travels through your gateway to the acquirer, out to Visa, Mastercard, or the local scheme, and back to the issuing bank. Approved means the funds are ring-fenced, not yet moved.
6. Capture and settle. You capture immediately for goods in stock, or later on shipment. Settlement lands in your account on your acquirer’s cycle — typically T+1 to T+3 in the GCC, longer if you’re settling cross-border into a different currency.
Where this gets interesting is what doesn’t happen in that sequence. There’s no 3D Secure step. And that changes everything about who pays when it goes wrong.
The thing your provider probably didn’t explain: MOTO has no liability shift
On a normal online checkout, you can route the cardholder through 3D Secure. They approve the payment in their banking app, the issuer confirms it was really them, and fraud liability shifts from you to the issuer. If a chargeback lands later, the bank eats it.
There is no 3D Secure for a phone call. The card networks have discussed MOTO authentication for years; issuers haven’t built it. UK and EU regulators formally exempt MOTO from Strong Customer Authentication — which sounds like a favour until you read the second half of that sentence. No authentication means no liability shift. If a caller reads out stolen card details, the chargeback is yours. Every time.
That’s not a reason to avoid virtual terminals. Card-not-present fraud is a large and growing category — UK Finance counted 1.98 million CNP fraud cases in the first half of 2025 alone, a 19% rise year on year — and the merchants losing money to it are overwhelmingly the ones treating MOTO as a casual side channel rather than a controlled one.
It is a reason to run it deliberately:
- Set a per-transaction ceiling. Above it, require a second approver or switch to a pay-by-link.
- Treat AVS or CVV mismatches as a hard stop on new customers, not a warning to click through.
- Flag the classic pattern: urgent order, large value, new account, delivery address that doesn’t match billing, buyer who pushes back on any verification.
- Watch velocity — same card across multiple orders, or multiple cards from one caller.
Real-time fraud screening rules do this automatically at the gateway layer, which is where it belongs. Asking a sales agent under quota pressure to be your fraud team is asking them to fail. And when a dispute does arrive, structured chargeback handling with the auth logs, AVS response, and call reference attached is what turns a guaranteed loss into a winnable one. Our guide on how chargebacks work walks through the representment timeline in detail.
What it does to your PCI scope
This is where virtual terminals get a bad reputation, usually unfairly.
Under PCI DSS, a merchant whose only card acceptance is manual entry into a browser-based virtual terminal on an isolated machine falls under SAQ C-VT — a short self-assessment questionnaire. If card data never touches your systems at all, you’re in SAQ A territory, the lightest tier there is.
The difference comes down to one question: does a card number ever exist inside your walls?
It does if agents write numbers on notepads, paste them into a CRM field, email them between departments, or if your call recording captures the digits. Every one of those pulls your entire network into scope and turns a two-page questionnaire into a genuine audit.
It doesn’t if you use a hosted terminal where the card fields are served by the gateway, tokenise on first use so repeat customers never need to re-read their number, and either pause call recording during payment or use DTMF masking — the customer keys digits on their handset, the agent hears flat tones, and nothing reaches the recording.
Get those three controls in place and PCI stops being the reason you avoid phone payments. Our PCI approach is built around keeping merchants in the lowest applicable SAQ tier by default, and the PCI DSS basics guide covers what each level actually asks of you.
What changes in the Gulf
Global guidance gets you most of the way. These five details are where GCC merchants get caught out.
Domestic schemes behave differently. Saudi Arabia’s mada network runs on infrastructure spanning over 225,000 POS terminals nationwide, and mada acceptance rules for card-not-present transactions aren’t identical to Visa or Mastercard’s. Confirm MOTO eligibility with your acquirer before you promise a customer anything — don’t assume scheme parity.
Currency precision breaks reconciliation. The Kuwaiti dinar, Bahraini dinar, and Omani rial use three decimal places. Systems built for two-decimal currencies quietly round, and you discover it during a month-end variance hunt. Test a KWD transaction end to end before go-live.
Tax and invoicing are not optional. VAT sits at 15% in Saudi Arabia and 5% across the UAE, Bahrain, Oman, and Qatar. Saudi merchants also fall under ZATCA e-invoicing requirements, which means your payment record needs to reconcile cleanly against a compliant invoice. Capture the tax treatment at the point of the transaction, not in a spreadsheet afterwards.
Arabic matters more than a language toggle. Receipts, refund confirmations, and dispute correspondence in Arabic aren’t a nice touch in the GCC — for consumer-facing merchants they’re a trust signal, and in Saudi Arabia certain card documentation is required in Arabic by regulation.
Licensing determines who can settle for you. SAMA licenses payment service providers in Saudi Arabia; the CBUAE does the same in the Emirates. A foreign gateway without local licensing or a local partner will limit what you can do. If you’re weighing acquirers, our comparison of NMI, Authorize.Net, Stripe, and PayPal covers regional coverage alongside the feature differences.
“Isn’t this obsolete? Just send them a payment link.”
Fair challenge — and for many transactions, correct. Pay-by-link authenticates the cardholder, gets you the 3DS liability shift, and keeps card data out of your business entirely. Where it works, use it.
But it assumes the customer will stop, open a link, and complete a form. In Gulf B2B, plenty won’t. The procurement manager who has just agreed terms wants the order confirmed on the call. The elderly customer doesn’t use online banking. The buyer at a trade stand is holding a card and a coffee. The subscription renewal that failed at 2am needs rescuing before the account suspends.
Sending a link and hoping is a conversion decision disguised as a security decision. The right answer isn’t one channel — it’s both, with a rule for which one you reach for. Link by default. Virtual terminal when the deal closes on the call.
That’s why midcove treats the virtual terminal as one surface inside a single multi-gateway platform rather than a bolted-on extra: same customer record, same transaction dashboard, same reporting, whichever way the money came in.
Setting one up without creating a mess
Five things, in order:
- Confirm MOTO is enabled on your MID. Many merchant accounts are provisioned e-commerce-only. Check before you build a process around it — and if MIDs are new territory, start with what a merchant ID actually is.
- Give every agent their own login with scoped permissions. Taking payments, issuing refunds, and viewing full transaction history should be three separate rights, not one.
- Tokenise on first payment. Repeat customers never read a card number aloud again, which removes your largest recurring exposure.
- Write down your fraud thresholds. Amount ceiling, AVS/CVV policy, escalation path. A rule that lives in one manager’s head isn’t a rule.
- Rehearse the refund path. MOTO customers dispute by phone. If your team can’t process a refund in under two minutes, they’ll hear about it as a chargeback instead — refund tooling that agents can actually operate pays for itself in disputes avoided.
The short version
A virtual terminal is browser-based card acceptance for payments agreed by phone, email, or post. It uses the same rails as your checkout, but with no 3D Secure, so you carry the fraud liability. Manage that with transaction ceilings, AVS/CVV enforcement, and tokenisation. Keep card data out of your systems and you stay in the lightest PCI tier. In the GCC, verify mada MOTO eligibility, three-decimal currencies, VAT and ZATCA handling, and your provider’s SAMA or CBUAE licensing before launch.
Every business has a set of customers who will never complete a checkout page. They’re often the ones spending the most. The question isn’t whether phone and mail order payments are modern — it’s whether you’re capturing that revenue on controlled infrastructure or turning it away because nobody set up the tooling.
Book a 20-minute demo with midcove and we’ll show you a live virtual terminal running against your own acquirer setup — MOTO eligibility, fraud rules, and PCI scope included.