Purchases
Purchases in the Business area (Revenue) — route /business/purchases.
Purchases lives in the Business area of the dashboard, under Revenue.
At a glance#
| Dashboard route | /business/purchases |
| Area | Business (business) |
| Group | Revenue |
| Platforms | Available for every app platform. |
What it does#
Purchases is the ingestion-quality view of revenue events. Every purchase arrives with a status:
Accepted — recorded.
Rejected — refused, with the error visible.
Duplicate — a transaction id already seen.
Each row carries revenue, currency, transaction id and the linked profile, and opens a drawer with the raw payload and any errors.
Transactions is the ledger of what counted. This page is where you find out what did not, and why.
When to use it#
Whenever revenue numbers look wrong. Every other revenue figure in the dashboard is built from accepted purchases, so a rejection rate you have not noticed silently understates all of them.
Also as the first stop when integrating revenue tracking. The rejection reason tells you exactly which field is malformed, which is far faster than inspecting your own payloads.
Workflow#
Filter to rejected and read the errors
This is the whole value of the page. Each rejection names its cause.
Check the duplicate count
Duplicates are usually a retry without idempotency, or a purchase handler that runs twice on remount. They are caught rather than double-counted, but they mean your client is sending them.
Open the raw payload
When a rejection is unclear, the payload as received settles it. What you think you sent and what arrived are occasionally different.
Fix and confirm
Re-check after a release. Rejections should go to zero and stay there.
Permissions and prerequisites#
Requires revenue-bearing tracked events. Nothing to configure here.
Limits and edge cases#
Duplicate detection is by transaction id. A purchase sent twice with different ids is counted twice and no warning is possible. Always send a stable transaction id.
A rejected purchase is not revenue. It is excluded from every aggregate, which is correct and is why the rejection rate matters.
Client-reported. A purchase your client never learns about — completed by a server-side webhook — does not appear at all, so it is neither accepted nor rejected.
Subject to retention.
Troubleshooting#
Revenue lower than the payment provider reports. Check the rejected count here first, then look for purchases the client never sent.
Everything is rejected. A payload field is wrong for every event — currency format and amount type are the usual suspects. The error text says which.
Legitimate purchases marked duplicate. Your transaction ids are not unique. A per-purchase id, not a per-product or per-user one.
Where the data comes from#
Deduplicated on transactionId; a fresh value per retry double-counts revenue.
From the SDK
Served by
Subscriptions
Business impact