Outcome API
The Outcome API lets you tell Shield what happened to a transaction after Shield cleared it. When Shield clears a transaction it knows the request looked legitimate, but it has no way of knowing whether the user went on to complete a billed subscription, failed a PIN, abandoned the flow, or hit a carrier error. Reporting that outcome back closes the loop.
With outcome data in hand, Shield can move from blunt attempt-counting toward subscription-aware decisions: distinguishing a fraudster stacking subscriptions from a legitimate user retrying after a failed PIN, building per-service conversion baselines, and grounding overblocking disputes in real billing history rather than assumptions.
Beyond fraud prevention, outcome data exposes where conversion is leaking — technical faults in the billing flow, or services running tighter than they need to — turning lost revenue into something you can see and act on.
Reporting is one-way and asynchronous. It never sits in the billing path and never blocks a sale. You bill as normal, then report the result.
How it fits the Shield flow​
Every protected transaction already carries a Shield transaction unique ID — the token returned in the Block API / snippet response. The Outcome API reuses that same identifier as its key:
- A user lands on the protected page; Shield issues a transaction unique ID and a Shield decision (cleared / suspect / blocked).
- For cleared transactions, your platform proceeds to billing as it does today.
- Once the billing attempt resolves — success or failure — you send one outcome report referencing that transaction unique ID.
Because the key is the ID Shield already issued, no new correlation mechanism is needed. If Shield never issued the ID you report, the call is rejected.
See the API spec here: Outcome Reporting Endpoint