Receipt Verification & Presentation
Using ACK Receipts (Verifiable Credentials) for payment proof.
A core component of ACK-Pay is the verifiable proof of payment. The ACK Receipt system provides cryptographically secure proof using W3C Verifiable Credentials (VCs). This allows Server Agents or other relying parties to validate payments reliably without needing direct access to underlying payment systems or trusting the Client Agent’s claim alone.
ACK Receipt Format (Verifiable Credential)
ACK Receipts are structured as Verifiable Credentials. This provides several benefits:
- Standardization: Leverages the mature W3C VC data model.
- Cryptographic Security: Receipts are digitally signed by a trusted Receipt Service, ensuring authenticity and integrity.
- Interoperability: Can be processed and verified by any system understanding the VC data model.
- Selective Disclosure: Allows for future extensions where only specific parts of the receipt might be shared (though typically the full receipt is needed for payment verification).
Example ACK Receipt Verifiable Credential:
See the W3C Verifiable Credentials Data Model specification for more details on the general structure.
Receipt Verification Process
When an ACK Receipt is presented by a Client Agent to a Server Agent (e.g., when retrying a request after payment), the Server performs these verification steps:
Validate Signature
Verify the cryptographic signature (proof
) on the VC using the public key
associated with the issuer
’s DID. This ensures the receipt hasn’t been
tampered with since issuance.
Confirm Issuer Trust
Check if the issuer
DID (e.g., did:web:receipts.example.com
) is present
in the Server’s configured list of trusted Receipt Services for the relevant
context or payment method.
Check Revocation Status
Verify that the receipt has not been revoked by the issuer. This typically involves checking a revocation mechanism specified by the Receipt Service (e.g., querying a status list endpoint).
Verify Payment Details
Examine the claims within credentialSubject.paymentToken
,
credentialSubject.paymentOptionId
, and credentialSubject.metadata
to
ensure they match the service requirements: - Is the original paymentToken
valid and correctly signed? - Is the paymentOptionId
valid and matches an
expected payment option? - Is the recipient
correct (e.g., does it match
the Server Agent’s expected identifier)? - Is the amount
, currency
, and
decimals
sufficient for the requested service? - Does the id
match the
one originally issued (if applicable in a Server-Initiated flow)? - Are the
credential issuanceDate
and settlement timestamp
values recent enough,
or has the receipt potentially expired based on policy?
If all these checks pass, the Server can confidently treat the payment as valid and proceed with service delivery.