Things engineering teams ask on the first call.
The top pre-integration questions a technical partner asks on the first call. Each answer ties back to the verification layer Provably actually runs — counterparty, payload, moment — not a sales pitch.
How does Provably record a verification decision?
Configured provider callbacks are signature-checked before the decision is normalized to pending, verified, or rejected. The separate x402 path binds a payment proof to a transactionId and uses HMAC-SHA256 checks. This is not a generic proof that a counterparty signed arbitrary payload terms.
What does the public receipt contain?
The public receipt selects status, verifiedAt, and x402PaymentId. It does not expose the VERIFY bearer, token hash, provider evidence, session identifier, or raw payload. A receipt is a verification reference, not a complete export of the underlying provider record.
How does the x402 payment flow fit into Provably?
POST /api/verify returns 402 with PAYMENT-REQUIRED when a valid X-PAYMENT proof is missing. A supplied proof must match the request transactionId, quoted amount, and payTo address and pass the HMAC-SHA256 check. If an x402 facilitator is configured, the server proceeds only after its settlement response succeeds; without one, the route proceeds after local proof validation.
Does Provably guarantee settlement?
No. Provably does not custody funds. The payment gate validates the transaction-bound x402 proof and may call a configured facilitator, but Provably does not guarantee that a separate payment rail completed settlement. With no facilitator configured, a successful local proof check is not evidence of an external settlement.
How do you handle regulated or private payloads?
Public receipt and explorer responses omit provider evidence, session identifiers, token hashes, and raw payloads. Provider evidence may remain in an internal Verification record for reconciliation. The current implementation does not promise that underlying provider payloads are encrypted or unrecoverable, and it does not construct a formal zero-knowledge proof.
Does Provably establish regulatory compliance?
No. Provably records verification outcomes and exposes a limited receipt; it does not determine whether an organization meets GDPR, EU AI Act, NIST AI RMF, ISO 42001, or another regulatory obligation. A verification record is not a compliance certification or legal opinion.
What does a first integration actually look like?
Start with the transactionId required by POST /api/verify. The route returns a 402 payment challenge until a matching X-PAYMENT proof passes its amount, payTo, transaction binding, and HMAC checks. See the API documentation for the current request and response shapes; integration time depends on your application.
How do AI agents get a delegated identity, and how is it bounded?
The /api/delegations route requires a current VERIFY bearer for a verified human record. It stores supplied agent IDs, signature fields, and expiries under that human and lists records with future expiries. The current API does not enforce delegation scopes or provide a manual revocation operation.
For technical evaluators
Need the wire-level security boundary behind the verify and x402 flows?
Read the security model