Interface MppFetchResultExperimental

How many credentials were minted and presented to the endpoint during this call (0, 1 or 2). This is NOT the same as settled: credentialsPresented > 0 with settled: false means the seller may already have burned credits for a credential whose fate is unknown to the caller — treat that as "do not blindly retry", not as "nothing happened".

TOTAL credits named by every challenge a credential was minted against during this call, as a decimal string — summed, not the last turn's amount, since a re-challenge is free to name a different price and the caller is accounting for the call. Present whenever credentialsPresented > 0.

It is an upper bound on what may have burned, never a lower one. A seller that answers a retryable code while replaying the identical challenge id gets a second credential minted against that same challenge (a code decides alone — see mppFetch), and against a seller that keys single-use on the challenge id, as this SDK's middleware does, that second credential is refused as a replay and burns nothing. The count is deliberately not lowered for it: this field answers "what could have left", and guessing which of a remote's credentials it honoured would answer a question the buyer cannot see.

Whether a credential was presented AND the final response looks successful: response.ok && settled. A 2xx with no receipt (a settlement that silently failed) and a non-2xx with a receipt (settle- then-error) are both paid: false — check settled and credentialsPresented for the honest picture in either case.

ok: true, paid: false, credentialsPresented: 1 is a ROUTINE outcome, not an exotic one: a seller whose handler streams or flushes has already sent its headers when settlement runs, so Payment-Receipt cannot be attached to a response that is already on the wire (this SDK's own middleware says so where it settles detached). The credits were burned. Never read this combination as "the payment did not happen" and retry.

The decoded Payment-Receipt, when the server returned one and it decoded cleanly. A malformed receipt never throws — it leaves this absent (with a console warning) rather than destroying a response the caller already paid for.

The final response — the paid one when a payment happened.

Whether the endpoint returned settlement evidence: a Payment-Receipt that decoded cleanly and does not state failure outright. Never derived from the HTTP status.

receipt.status is read asymmetrically, on purpose. Success is NOT recognized — 'success' is the only value with agreement behind it, so treating an unrecognized 'ok'/'completed' as failure would report an unpaid call that was in fact paid. An explicit negative ('failed', 'failure', 'declined', 'error') is a different thing from an unknown vocabulary, and is excluded: paid: true on a receipt that says the settlement failed is wrong in the one direction this field must never be wrong. Anything else stays settled: true with receipt on the result, so a caller paying third parties can judge the value itself.

This SDK's own seller attaches a receipt only when settlement succeeded, so the distinction is third-party exposure rather than in-ecosystem.