Decision audit
Decision audit makes every payment decision reviewable after the fact. Each instruction is recorded with its inputs, matched policy rules, reason codes, confidence and the policy version in force, so “why was this payment blocked?” has an exact, replayable answer instead of a reconstruction.
“Why was this payment declined?” shouldn't be archaeology
When payment logic lives in application code, explaining a historical decision means digging through deploys, logs and tribal memory. Disputes, internal reviews and compliance questions all land on the same gap. There is no record of what was evaluated, which rules matched, or what the rules even were at the time.
Records built for review, not reconstruction
- 01Recorded as a side effect of decidingEvery POST /v1/decision produces a full decision record of inputs, matched rules, instruction and confidence, with no extra logging work on your side.
- 02Reason codes on every instructionEach decision carries structured reason codes stating exactly why the instruction was chosen.
- 03The policy version is part of the recordPolicy is versioned, so the rules in force for any given decision are a matter of record. Any decision can be replayed against them.
- 04Outcomes complete the storyResults reported to /v1/outcomes are joined to their decisions, so a review sees what was decided and what then happened.
The products behind it
Every solution is the same four-part architecture doing its job. These are the parts doing the heavy lifting here.
Frequently asked questions
Common questions about decision audit with Payinference.
Deciding what should happen to a payment before it touches a rail. Payinference evaluates provider health, cost, risk and your merchant policy in real time and turns them into a single instruction with reason codes, so routing, retries, step-ups and blocks are deliberate, explainable decisions instead of static defaults.
In shadow mode Payinference returns decisions and records what it would have done while your existing logic keeps executing, so you can evaluate decision quality against real traffic with zero risk. In enforce mode your stack executes the returned instruction.
Two endpoints. Your backend calls POST /v1/decision with safe payment context and receives one instruction. You execute that instruction through your own providers, then report what happened to POST /v1/outcomes so future decisions keep improving. A server-side SDK wraps both calls.