Validate transaction data
POST/v2/config/digital-wallet/openid/sdjwt/transaction-data
Validates the transaction data that a holder approved during an OID4VCI credential issuance.
The server reads the key binding JWT of paymentWalletAttestation, calculates the hash of the transaction data, and compares it with the hashes in the key binding JWT. It then stores the result. Read transactionDataVerified of the answer to see the result.
Rules that the server applies:
- Send the payload in
transactionDataor intransactionDataBase64, but not in both. transactionDataHashesAlgmust hold exactly one value, and that value must besha-256.- The organisation must have a key.
Request
Header Parameters
Optional. Unique identifier of the sandbox organisation to use for this request. When you send this header, the service runs the operation in the context of the named sandbox organisation, that is, against the wallet of that sandbox organisation and not against the main wallet of the organisation. Leave the header out to use the main wallet.
The service reads this header only when you authenticate with a bearer access token. When you authenticate with an API key, the service takes the sandbox organisation from the API key and ignores this header. To run an API-key call in a sandbox organisation, bind the key to the sandbox organisation with PUT /v2/config/admin/apikey/{apiKeyId}/sandbox-org instead.
X-SubwalletId is the deprecated name of this header. The service continues to accept it, but X-SandboxOrgId wins if you send both headers.
The sandbox organisation must exist, must belong to your organisation and must be deployed. An unknown identifier, an identifier of a sandbox organisation that is not deployed, and an identifier that belongs to a different organisation all make the call fail with HTTP 400.
- application/json
Body
required
Transaction data and the Payment Authenticator presentation that proves the holder agreed to the transaction.
Payment Authenticator Verifiable Presentation token that the holder sent. The token must hold a key binding JWT with the transaction data hashes.
Possible values: [sha-256], >= 1, <= 1
Hash algorithm that the key binding JWT uses for the transaction data hashes. Give exactly one value, and the only supported value is sha-256.
transactionData object
Transaction data payload in plain JSON. Send this property or transactionDataBase64, but not both.
Transaction data payload in plain JSON. Send this property or transactionDataBase64, but not both.
Transaction data payload as a base64url encoded string, in the form that the OpenID4VP Authorization Request carries. Send this property or transactionData, but not both.
Responses
- 200
- 400
- 401
- 500
The issuer validated the transaction data and stored the result.
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
transactionDataHistory objectrequired
The stored transaction data record. Read transactionDataVerified to see the validation result.
Internal record identifier of the transaction data record. It is not the same value as transactionDataId. Always use transactionDataId to address the record.
Unique identifier that the server gives to the transaction data record. Use this identifier in the path of the read endpoint.
Identifier of the credential issuance history record that this transaction data belongs to. The value is an empty string when the record belongs to no credential issuance.
Identifier of the OpenID4VC deployment that validated the transaction data.
Base64url encoded transaction data strings that the issuer verified against the key binding JWT. The value is null when the issuer verified no string.
Payment Authenticator Verifiable Presentation token that the holder sent.
transactionData object
Transaction data payload in plain JSON, for example the payee and the amount of a payment. The value is null when the request gave the payload as transactionDataBase64.
Transaction data payload in plain JSON, for example the payee and the amount of a payment. The value is null when the request gave the payload as transactionDataBase64.
true when the issuer verified the transaction data hashes against the key binding JWT.
vpTokenDecoded object
Decoded payload of the Verifiable Presentation token that the holder sent. The value is null when the issuer could not decode the token.
Decoded payload of the Verifiable Presentation token that the holder sent. The value is null when the issuer could not decode the token.
Unix timestamp, in seconds, of the moment that the server created this record.
Unix timestamp, in seconds, of the moment that the server last changed this record.
{
"transactionDataHistory": {
"id": "string",
"transactionDataId": "string",
"credentialExchangeId": "string",
"openIdOrganisationId": "string",
"transactionDataBase64s": [
"string"
],
"paymentWalletAttestation": "string",
"transactionData": {},
"transactionDataVerified": true,
"vpTokenDecoded": {},
"createdAt": 0,
"updatedAt": 0
}
}
The request is not valid. The server returns this status when paymentWalletAttestation or transactionDataHashesAlg is missing, when the body holds both transactionData and transactionDataBase64 or none of them, when transactionDataHashesAlg does not hold exactly one sha-256 value, when the organisation has no key, or when the validation fails.
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
{
"errorCode": 400,
"errorDescription": "Bad input parameter"
}
Unauthorized
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
{
"errorCode": 400,
"errorDescription": "Bad input parameter"
}
Internal server error
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
{
"errorCode": 400,
"errorDescription": "Bad input parameter"
}