HyperPay
HyperPay processes payments for a large number of regional merchants. The assistant case is the ordinary one for any gateway: status, failures and refunds.
HyperPay processes payments for a large number of regional merchants. The assistant case is the ordinary one for any gateway: status, failures and refunds.
What HyperPay holds, and why that matters here
HyperPay is a payment gateway widely used across the Gulf, handling card and local payment methods for online merchants. The contact it produces is transactional and repetitive.
For merchants, the value is answering customer payment questions without routing them to a finance or technical team who then look up the same record.
- Transaction status — successful, failed, pending.
- Failure reasons — the category of failure and the appropriate next step.
- Refunds — status and expected timing.
- Payment methods — which were used and which are available.
- References — linking a payment to an order.
Questions Elbi can answer from HyperPay
Did my payment work?
Transaction status against the order.
Why did it fail?
Failure category and what to try next.
Where is my refund?
Refund status and timing.
What payment methods do you take?
Available methods, which is a pre-purchase question.
Can I pay differently?
Alternatives where a method has failed.
Was I charged?
Confirming whether a failed attempt resulted in a charge — a common anxiety.
How a HyperPay lookup works
- The customer is identified firstA payment question is about one person's money, so the assistant establishes who is asking before it reads anything, through your own sign-in. An order number on its own is not proof of identity; it gets forwarded, screenshotted and read out over the phone.
- The order is matched to a transactionMerchants usually pass their own order reference to HyperPay at checkout. The assistant looks the transaction up by that reference, or by the HyperPay payment ID, so the customer never has to dig a gateway reference out of an email.
- It reads the result, not the cardWhat comes back is the transaction result, the amount, the time, the card brand or method used, and any refunds recorded against it. Card numbers and CVV codes are not part of that view and are never asked for in the conversation.
- Result codes become plain reasonsHyperPay returns a result code and a description with each transaction. The assistant maps those onto a short list of reasons a customer can act on — declined by the bank, authentication not completed, still pending — instead of reading a code aloud.
- The next step is offered, not takenIf a payment failed, the assistant can suggest another method you accept or a fresh attempt. It does not start a payment in the chat: the customer goes back to your checkout, which is where card details belong.
- Money decisions go to your teamRefund requests, disputed charges and anything heading towards a chargeback are passed to the staff who own them, with the HyperPay reference attached so nobody has to search for it twice.
Scope and control over HyperPay access
| Direction of access | Read-only against transactions and refunds. The connection does not capture, reverse or refund a payment; those actions stay in HyperPay's merchant dashboard or your back office, with the people who already hold that authority. |
|---|---|
| Card data | Out of scope entirely. PCI DSS is the reason card numbers and CVV codes stay out of the conversation: an assistant that never sees them adds no new place where card data could leak. |
| Who can see what | A customer sees only transactions tied to their own verified identity. Finance or support staff using the assistant internally see what their role allows, as established by your sign-in. |
| Credentials | API credentials from your HyperPay merchant account, kept for this connection alone and used by it only for status and refund-status queries. You issue them, you can rotate or revoke them on your side, and the connection stops the moment you do. |
| Where data goes | A transaction record read to answer a question is used for that answer. Conversation content is destroyed within 24 hours, usually when the conversation ends, and no external AI service sees it. |
| Audit | Each lookup can be logged — which query ran, for which conversation and when — so finance and compliance can see exactly what the connection did. |
| If HyperPay is unreachable | The assistant says it cannot check the payment right now and offers a person. It never tells a customer that a payment succeeded or failed without having read the record. |
What this replaces
The most useful thing here is resolving the failed-payment anxiety. A customer whose payment failed frequently does not know whether they were charged, and that uncertainty produces immediate contact and sometimes a duplicate attempt.
Answering it directly — confirming whether a charge exists and what to do next — resolves the concern and frequently recovers the sale.
Refund timing is the second. Merchants know refunds take a defined period; customers do not, and the gap produces repeated contact.
Where HyperPay questions come from
E-commerce
Payment failure and refund questions.
Subscription services
Recurring payment failures and retries.
Marketplaces
Multi-party payment status.
Any online merchant
Recovering abandoned transactions after a failure.
Getting value from HyperPay data
Start with the question that arrives within minutes of a failed checkout: was I charged? It is the most anxious payment question and one of the easiest to answer from HyperPay, because the transaction result is already recorded. A clear reply — no charge was taken, or the payment went through and the order stands — heads off the second attempt that later becomes a duplicate-charge complaint.
Refund status is the next one worth connecting. HyperPay records when your side processed a refund; what happens after that depends on the customer's bank. The assistant should say both halves plainly — the date you sent it and the period you publish for it to appear — without promising a day the bank has not committed to.
Then come the questions asked before anyone pays: whether you take mada, Apple Pay or a particular card, or whether there is a pay-later option. These need no transaction lookup, only an accurate list of the methods enabled on your HyperPay account, updated whenever that list changes.
What connecting HyperPay involves
- Rank the payment questionsSort recent payment contact by type — failed, charged twice, refund, method. The ranking decides which HyperPay fields the connection needs; for most merchants that is result, amount, time, brand and refund records, and nothing else.
- Check how orders reach HyperPayConfirm which reference your checkout sends with each payment and that it is consistent across web, app and any other channel. If the order number is not carried through, no assistant can match an order to a transaction, and the fix belongs in the checkout.
- Issue credentials for this useYour team obtains API credentials for the merchant account and gives them to this connection only. They remain yours to rotate or revoke without involving us.
- Agree the failure categoriesYour payments or finance lead decides how HyperPay's result codes group into the reasons a customer will hear, and the next step for each. This is what makes answers useful rather than merely correct.
- Test the awkward transactionsSuccessful, declined, abandoned at authentication, pending, partly refunded, paid twice. Each is checked against a test environment or historical records before a customer sees an answer.
- Go live on status firstLaunch with "did it work" and "was I charged", then add refunds and payment methods once the answers match what your staff would have said.
Governing payment records under PDPL
A HyperPay transaction ties a named person to an amount, a time and a purchase. That makes it personal data under the Saudi Personal Data Protection Law, and financial in character. Reading one transaction to answer the customer's own question about it is a narrow purpose that is easy to explain; browsing their wider payment history is a different purpose and should not ride along with it.
The design follows from that. The assistant reads the transaction being asked about rather than everything on the account, discloses nothing until the person is identified, and keeps card data out of the conversation altogether. If a customer offers a card number anyway, the assistant does not take it and points them back to the checkout.
Other ways merchants handle HyperPay questions
Most merchants answer payment questions by hand: a support agent opens the HyperPay merchant dashboard, searches by order or amount, reads the result and replies. It works, and it is exactly where the delay comes from, because it waits for someone with dashboard access to be free.
Some of the volume can be removed at source. A failure page that says whether money was taken, a confirmation email sent only once payment succeeds, and a published refund period all stop questions before they are asked, and are worth doing whatever else you do. HyperPay can also notify your server of payment outcomes, so your own order pages show the right status to a customer who checks there first.
A connected assistant sits after those measures, for the questions that still arrive. Where it goes wrong is predictable: answering before the customer is identified, repeating a raw result code, or saying a refund will land tomorrow when that date belongs to the customer's bank.
What merchants typically see with HyperPay connected
Common questions
It can explain what failed and offer an alternative, which frequently recovers the sale.
No. It reports status; issuing is a financial decision with a person.
No. It works with transaction status and references, not card data.
No. The connection runs between your assistant and your HyperPay account, using credentials you issue, and reads only the transaction fields agreed for it. Revoking those credentials on your side ends it.
Each gateway is connected separately, with its own credentials and scope. The customer still asks one question about their order, and the answer comes from whichever gateway processed it.
No. Payment details are never taken in the conversation. The assistant sends the customer back to your checkout, where the card is handled by the payment form, not by a chat window.
Connect Elbi to HyperPay
Payment status, failures and refunds answered from your own HyperPay records, in Arabic and English.