- no redirect to Points checkout
- no customer-facing UI changes
- one primary API call:
POST /v1/orders/earning
When to choose Earn-only
Use this flow if:- you want to launch quickly
- your current checkout should remain unchanged
- you only need to award points after purchase
- you can add one server-to-server API call after payment succeeds
Flow overview
Required inputs
Every earning request should include:| Field | Required | Notes |
|---|---|---|
phone_number | Yes | KSA mobile format |
total_price | Yes | Total paid amount in SAR |
order_number | Yes | Your merchant-side unique order reference |
products | Yes | Array with at least one item |
metadata | No | Useful for cart, channel, branch, or POS context |
Example request
Successful response
uuid. You will need it later for:
- refunds
- lookups
- reconciliation
Important runtime behavior
If the customer is not yet fully engaged
The backend supports a pending earning flow for customers who exist but have not completed app engagement yet. That means an earning attempt may not behave exactly like a normal approved order in every edge case. Your system should always inspect the returned response instead of assuming one fixed downstream state.Concurrency
Earning requests are serialized per merchant through a distributed lock. If you send too many concurrent requests for the same merchant, the API may return429.
Practical advice:
- do not parallelize multiple earning calls for the same merchant
- retry with a short back-off if you receive
429
Deduplication
Use a uniqueorder_number from your system. Even when the API accepts the request, your own system should still treat order_number as the source of truth for idempotent retries.
When to call the API
CallPOST /orders/earning only after the purchase is actually confirmed in your own system, such as:
- successful PSP callback
- order marked paid in POS
- COD order marked collected
Recommended reconciliation
- Create the earning order after your payment succeeds.
- Store the returned
uuid. - If your worker crashes after the call, use your stored
order_numberand internal audit log to detect the partially completed step. - For disputes or support, fetch the order later with
GET /v1/orders/{uuid}.
Common errors
| HTTP status | Meaning | What to do |
|---|---|---|
400 | Missing or invalid API key | Verify x-api-key and environment |
403 | Merchant not verified/published or earn flow disabled | Contact Points support / account manager |
422 | Validation error | Check phone_number, products, total_price, order_number |
429 | Concurrent earning requests for the same merchant | Retry with back-off |
Next
Quickstart
Full first-call walkthrough with examples.
Refunds & Cancellations
What happens if an already-awarded order is later refunded.
Go-Live Checklist
Verify your production readiness before launch.

