Query resolution — business rules
The constraints, ownership rules, and escalation paths that govern merchant query resolution.
These rules govern how merchant queries flow through the Scan to Pay support process. For the workflow itself, see Merchant query resolution.
Ownership rules
| Issue type | Owner | Notes |
|---|---|---|
| Platform infrastructure (API downtime, webhook delivery failures, system errors) | Scan to Pay Operations | Raise via [email protected] or call the 24/7 line |
| Integration / API question | Scan to Pay Implementation team | Raise via [email protected] or [email protected] |
| Day-to-day operational (billing, portal management, account changes) | Scan to Pay Day-to-Day Support | Raise via [email protected] |
| Cardholder dispute / chargeback | Acquiring bank's disputes team | Scan to Pay's Dispute Management can advise — [email protected] |
| Settlement amount / timing | Acquiring bank | Not Scan to Pay — talk to your acquirer's settlement team |
| Card not honoured by issuer | Issuing bank | Not Scan to Pay — talk to the customer's bank |
| Branding / marketing collateral | Scan to Pay Marketing | [email protected] |
The first rule of resolution: make sure you're raising the query with the right party. Scan to Pay can't fix settlement timing problems, and your acquirer can't fix webhook delivery — different parties own different parts of the stack.
Required information
Every query should include at minimum:
| Field | Example |
|---|---|
| Company name | Acme Coffee Pty Ltd |
| Contact name and number | Jane Smith, +27 71 234 5678 |
| Scan to Pay merchant ID | 25 |
| Transaction ID (if a specific transaction is involved) | 81234 |
| Date and time the issue occurred (with timezone) | 2025-05-14 11:42 SAST |
| Brief description of the issue | "Webhook never arrived for tx 81234" |
| What you've already tried | "Checked our webhook receiver logs, no inbound request" |
For full template, see Support — what to include in a support request.
Cardholder PII restrictions
Never share these in a support ticket without encryption:
- Full card PAN (use BIN + last 4 only)
- Full card expiry date
- CVV / CVC
- PIN
- Full account number
Sharing this data in a regular email is a PCI DSS violation and will delay your case while the support team sanitises the channel. If sensitive data is required for investigation, the support agent will provide a secure channel (encrypted email, secure file drop) — wait for that before sending.
Subject-line discipline
When the support team creates a case for you, they reply with a unique tracking number in the subject line. Keep the subject line intact on all follow-ups — including the tracking number prefix. The ticketing system threads conversations by subject, and an edited subject can start a new case (losing context and slowing resolution).
Priority and response times
| Priority | Impact | Initial response | Update frequency |
|---|---|---|---|
| P1 Critical | Extensive / widespread — material impact on transactions | On inbound call | Every hour |
| P2 Major | Significant but localised — some users severely impacted | 1 hour | Every 3 hours |
| P3 Minor | Day-to-day operational queries | 1 business day | Every 2 business days |
Priority is assigned by the support team based on impact. If you believe a case has been prioritised incorrectly, request escalation — see Support.
Escalation rules
| When to escalate | How |
|---|---|
| No response within the priority's target window | Reply on the case and CC [email protected] |
| You believe priority is wrong | Same: reply with reasoning, CC escalations |
| P1/P2 incident impacting live traffic right now | Call +27 10 449 1784 directly — phone over email for live incidents |
| Multiple open tickets on the same root cause | Reply on each, ask for consolidation |
Don't open duplicate tickets. Reply on the existing one or contact escalations directly.
Documentation expectations
When a query is resolved, the support team typically:
- Provides an explanation of root cause (where known)
- Confirms the fix (your action, our action, or both)
- Notes any follow-up required (deploy a fix, reset state, contact a third party)
- Marks the case as resolved
Keep the resolution email — it's the audit trail if a similar issue recurs.
For platform-wide incidents that affected multiple merchants, the support team may also publish a post-mortem on the support portal. Check the support portal for recent incident write-ups.
What's next
- The query resolution process → Merchant query resolution
- Support channels and contact details → Support
- Recover a missed webhook (most-common query type) → Webhooks
- Cardholder disputes (different process, different owner) → Customer disputes
Updated 3 days ago