PayTabs
PayTabs is another widely used regional gateway, and the questions are the same: did it work, why not, and where is my money.
PayTabs is another widely used regional gateway, and the questions are the same: did it work, why not, and where is my money.
What PayTabs holds, and why that matters here
PayTabs provides payment processing for merchants across the Gulf and beyond, supporting card and local payment methods. As with any gateway, the customer-facing contact is transactional.
The merchant-facing case matters too — settlement timing and transaction reconciliation are questions finance teams ask constantly.
- Transaction status — success, failure, pending.
- Failure detail — the category and the appropriate next step.
- Refunds — status and timing.
- Settlement — when funds reach the merchant.
- References — linking payments to orders.
What customers and finance ask about PayTabs
Did the payment succeed?
Status against the order reference.
Why was it declined?
Category and next step, within what a merchant may disclose.
Where is my refund?
Status and expected timing.
When do we get settled?
Settlement timing for the merchant's own finance team.
Is this transaction ours?
Reconciliation questions against a reference.
What methods are supported?
Available payment options.
How a PayTabs connection behaves
- Two audiences, two scopesA shopper asking about a payment and a finance officer asking about settlement are different people with different rights. The connection is set up with a separate, named view for each, so the customer-facing assistant cannot answer a settlement question and the finance view does not need customer contact details.
- Customers are verified before any lookupThe shopper signs in through your own site or app, and only then does the assistant read the payments linked to that account. Knowing someone's order number is not enough to see their payment.
- Orders are found by your own referenceStores normally send their order or cart ID to PayTabs with each payment. The assistant searches by that, or by the PayTabs transaction reference, and returns the outcome, amount, currency and time.
- Declines are explained within limitsPayTabs records why a transaction did not complete. The assistant turns that into a reason the customer can act on — try another card, complete the bank's verification step, contact the issuing bank — without passing on issuer detail a merchant should not share.
- Finance gets settlement answersFor staff, the same connection answers whether a transaction has been settled and how a payout relates to the orders in it, from the settlement information your PayTabs account makes available. Nobody has to export a report to answer one line.
- Refunds and disputes stay with peopleThe assistant reports whether a refund exists and when it was processed. Starting one, or responding to a dispute, remains with the staff who hold that authority in PayTabs.
Scope and control for PayTabs
| Direction of access | Read-only. Transaction status, refund status and settlement information are read; nothing is charged, refunded or cancelled through the connection. |
|---|---|
| Customer view | A verified customer's own transactions, and only the fields needed to answer: outcome, amount, currency, time, reference and refund state. |
| Finance view | Settlement and reconciliation data for named finance staff, established through your sign-in. It can be limited to certain stores or currencies where you run more than one. |
| Card data | Never read, never requested. Keeping card numbers and CVV codes out of the chat is how the connection stays clear of what PCI DSS exists to protect. |
| Credentials | Keys generated in your PayTabs merchant account, kept for this connection and used by it only to query. You issue them, rotate them when you choose, and revoking them ends the connection at once. |
| Retention | Conversation content, including anything read from PayTabs, is destroyed within 24 hours and usually when the conversation ends. No external AI service processes it. |
| Audit | Lookups can be logged by type, time and conversation, which lets finance show who asked the assistant about settlement and when. |
What this replaces
The dual audience is the distinctive feature. Customers ask about their payment; the merchant's finance team asks about settlement and reconciliation. Both are answerable from the same connection with different entitlements.
For customers, the failed-payment case dominates, and resolving the "was I charged" anxiety quickly both reduces contact and recovers sales.
For merchants, settlement timing and reconciliation are recurring internal questions that currently occupy finance staff in exactly the periods when they are busiest.
Who asks PayTabs questions
E-commerce
Customer payment and refund status.
Merchant finance teams
Settlement and reconciliation questions.
Subscription businesses
Recurring payment handling.
Cross-border merchants
Multi-currency and multi-method questions.
Where a PayTabs connection pays off first
There is a case for starting with finance rather than customers. Settlement questions come from a small group of staff, the answers are internal, and a mistake is caught by a colleague rather than seen by a shopper. "Has yesterday's card revenue settled?" and "which orders make up this payout?" are asked repeatedly at month end, and both can be answered from data PayTabs already holds.
On the customer side, the declined payment is the one to connect first. A shopper who has just been declined wants to know whether to try again, try another card or call their bank, and they want it while they are still at the checkout. Answering in the language they asked in, Arabic or English, matters more here than almost anywhere else.
Refund status follows. The useful answer separates what the merchant controls from what the customer's bank controls: when you processed the refund, and the period you publish for it to reach the card. Anything after that is between the customer and their bank, and the assistant should say so rather than guess.
Steps to connect PayTabs
- Name the two audiencesDecide who the customer-facing assistant serves and which finance staff may ask about settlement. Each gets its own written list of questions and fields.
- Check your order referencesConfirm that every channel sending payments to PayTabs includes your own order ID, and in the same format. Gaps here are the most common reason a payment cannot be matched to an order.
- Generate keys for this connectionAn administrator creates API keys in the PayTabs merchant account for the assistant's use alone, so they can be revoked without touching your checkout.
- Write the decline wordingGroup the reasons PayTabs records into a handful of customer messages, each with a next step, and have them signed off by whoever owns payments.
- Rehearse with financeRun a period's real settlement questions through the finance view and compare the answers with your reconciliation. Differences are resolved before anything goes to customers.
- Open to customersStart with payment status and declines, then add refunds once staff agree the answers match what they would have written.
Personal data in PayTabs records
Alongside the payment itself, a PayTabs transaction usually carries the customer's name, email and phone number. Under the Saudi Personal Data Protection Law those details should reach only the verified customer they belong to, or staff whose role needs them. The finance view rarely does: settlement questions are about amounts, dates and references, so the connection can leave contact details out of that view altogether.
Where a customer's question needs their own details — which email the receipt went to, for instance — the assistant confirms against what the customer has told it rather than reading the full record back. The less it repeats, the less there is to go wrong.
How PayTabs questions are usually handled
Without a connection, customer payment questions go to support, who look the payment up in the PayTabs merchant dashboard, and settlement questions go to finance, who export transaction and settlement reports and reconcile them against bank statements. Both work; both depend on a few people with dashboard access.
PayTabs can also send your server a callback when a payment completes, which lets your own order system and emails reflect the outcome immediately. Merchants who use it well see fewer "did my payment go through?" questions to begin with, and it is worth getting right before connecting anything else.
What a connected assistant adds is the question nobody anticipated in a report or an email. The failure to avoid is letting the two audiences blur: a customer should never receive a settlement answer, and a finance question should never need a customer's contact details.
What merchants see once PayTabs is connected
Common questions
Yes, with different entitlements. A customer sees their transaction; finance sees settlement.
No. It reports status; issuing is a financial decision.
No. Transaction status and references only.
No. The connection runs between your assistant and your PayTabs account with keys you issue, and settlement data is visible only in the finance view you define. Revoke the keys and it stops.
The assistant reports the amount and currency as PayTabs recorded them. It does not convert between currencies or quote exchange rates.
They can be told how to retry, but not inside the conversation. The assistant points them back to your checkout; card details are never typed into a chat.
Connect Elbi to PayTabs
Payment answers for customers and settlement answers for finance, from one PayTabs connection, in Arabic and English.