Handshake AI Payments: Turning Agent Receipts Into AP Evidence

Handshake AI payments refers here to Handshake.AI’s proposed role as an attestation layer for agent-driven payments: issuing cryptographically signed receipts that help establish which service attested to an action and whether the recorded result has changed. It should not be confused with a payment rail, an invoice approval policy, or proof that a supplier received funds.

For CFOs and controllers, the useful question is not whether an agent can produce a signed record. It is whether that record helps reconstruct a payable from the original invoice through authorization, execution, and reconciliation.

The distinction matters: a verifiable receipt can preserve evidence of a bad decision just as faithfully as a good one. Finance still needs controls that determine which actions are allowed before money moves.

What Handshake.AI adds to the payment workflow

Handshake.AI describes its offering as an audit and assurance layer around agent protocols and tool calls. Its stated approach includes signed receipts containing a hash of the result and the issuing service’s decentralized identifier, or DID, with signatures that can be verified against a public key.

In practical terms, a hash acts as a fingerprint of the recorded data. If the underlying data changes, recomputing the hash should reveal the mismatch. The signature helps establish that the receipt was signed by the holder of the corresponding private key. Neither mechanism independently establishes that the underlying business action was legitimate.

Handshake.AI also positions itself as an attestation layer for AP2’s payment mandate model. Google’s AP2 announcement describes a protocol intended to support secure, accountable agent-driven transactions through verifiable authorization records. The useful distinction is between documenting permission and documenting what a service subsequently says happened.

These are vendor and protocol design claims, not evidence of independently verified deployment performance. Buyers should validate receipt coverage, integrations, and failure behavior rather than infer production readiness from protocol compatibility.

The brand is not the generic payment handshake

A payment handshake is a broader term for an exchange that establishes identity, permission, transaction terms, or payment evidence between systems. Handshake.AI is a specific offering. A vendor saying it supports an agent payment handshake does not necessarily mean it uses Handshake.AI or produces an equivalent evidence package.

Signed receipts are evidence, not a control verdict

Finance should separate several questions that a product demonstration may collapse into a single green checkmark:

• Integrity: Has the signed receipt or referenced result changed?
• Attribution: Which key signed it, and which trusted service controls that key?
• Authority: Was the action permitted under a valid delegation and company policy?
• Business correctness: Was the invoice genuine, correctly matched, and payable to this beneficiary?
• Financial outcome: Was the payment accepted, settled, returned, or credited to the recipient?

A signature primarily supports integrity and attribution, subject to key trust and security. Other claims require additional evidence. A service’s signed statement that it submitted a payment does not, by itself, establish bank acceptance or settlement.

Offline verification also has a boundary. It may establish cryptographic validity using available keys, but current revocation status, expired authority, or subsequently discovered key compromise may require additional information. Ask what the verifier checks and what it cannot know.

Build an evidence chain around the payable

The following is a recommended AP evidence design, not a claim that every field is included in Handshake.AI’s receipt schema. The objective is to link agent receipts to authoritative business records without asking auditors to reconstruct the workflow from chat transcripts.

Bind approval to the exact payment instruction

An approval attached only to an invoice number leaves room for the beneficiary, currency, amount, or execution date to change afterward. Instead, bind authorization to a versioned payment instruction. A material change should invalidate the prior authorization and trigger the appropriate review.

Keep policy enforcement outside the agent’s discretion. The agent can assemble the evidence, but a separate release service should check whether the instruction remains authorized. This extends the principles in our guide to AP fraud prevention controls that survive payment release.

Preserve the records behind the hashes

A hash is useful only if the corresponding evidence remains available. Retain the source invoice, relevant structured output, authorization record, and payment instruction under an appropriate access and retention policy.

Use a deterministic representation when hashing structured data so different field ordering or formatting does not create avoidable verification failures. Avoid putting unnecessary bank details or personal data into widely distributed receipts. Integrity protection is not confidentiality protection.

Design for missing receipts and uncertain outcomes

A payment request can time out after a provider has accepted it. Missing local evidence must not automatically trigger another transfer. Preserve a stable idempotency key where supported, query the provider’s status, and route unresolved cases for investigation.

Similarly, distinguish a missing receipt before submission from a receipt-delivery failure after submission. The former may justify holding release; the latter requires recovery and reconciliation, not an assumption that no money moved.

Where agents can act—and where people should intervene

Receipt coverage improves traceability, but it should not expand an agent’s authority by itself.

Within tested rules, an agent can propose invoice coding, match invoices to purchase orders and receiving records, and chase missing documents through approved vendor contacts. Each action should have a bounded scope and an exception path. A vendor document must remain input data, not a source of instructions that can rewrite payment policy.

Require human review for beneficiary changes, unresolved match exceptions, new delegations of spending authority, and attempts to override blocked payments. Straight-through payment release can remain a separate policy decision for eligible transactions; it should not depend on the model deciding that its own work is safe.

Configure approval policies around business risk and segregation of duties, then use receipts to document how those policies were applied. Our guide to AI agent payment approval boundaries covers that broader allocation of authority.

Hypothetical example: a correctly signed attempt to pay the wrong account

Consider an AP agent processing an invoice from an established supplier. The invoice includes a note asking for payment to a new bank account. The agent extracts the details and prepares a payment instruction. Its tool calls produce valid signed receipts.

The receipts establish what was recorded, but they do not authenticate the bank-account change. Under the recommended design, the payment instruction references a beneficiary version that differs from the approved vendor master. The release service blocks submission and routes the change to an authorized reviewer for independent verification.

After verification, the updated instruction receives fresh authorization. The evidence chain preserves the attempted change, the block, the reviewer’s decision, and the eventual provider reference.

The important outcome is not merely a signed payment. It is a signed, reconstructable history of the exception and its resolution.

A practical acceptance checklist for finance teams

Before using an attestation layer in a live AP workflow, require demonstrable answers to these questions:

1. Coverage: Which actions generate receipts, and can an agent bypass the instrumented path?
2. Trust: How are signing keys associated with approved services, rotated, and revoked?
3. Authorization binding: Does changing the beneficiary or amount invalidate existing approval?
4. Evidence export: Can finance retrieve receipts, source records, and verification material independently of the vendor console?
5. Failure recovery: What happens when signing, receipt delivery, or provider status retrieval fails?
6. Replay protection: Can an old instruction or receipt be reused to trigger another payment?
7. Outcome verification: Which provider or bank evidence supports each payment status?
8. Exception ownership: Who investigates missing evidence, mismatched records, and compromised credentials?

Start with a bounded invoice workflow and deliberately test changed instructions, expired authority, duplicate submissions, and missing receipts. Evaluate whether each case produces a safe decision and a recoverable evidence trail—not just a technically valid signature.

Make attestation useful to the ledger

Handshake.AI’s proposed value is making agent actions more verifiable. Finance creates the operational value by connecting those attestations to approved obligations, controlled payment instructions, and independently sourced financial outcomes.

Payouts.com brings AP/AR automation, global payouts, treasury, and AI digital employees into a financial operating system on one ledger. When evaluating AP automation, use the evidence chain above as a workflow requirement. Do not assume a Handshake.AI integration or protocol support without confirmation.

The next step: choose a payable and ask whether someone outside the workflow could reconstruct who authorized it, what changed, what was sent, and what ultimately happened to the money. That is the standard an agent receipt should help satisfy.

Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.