---
title: "Transaction Data Profiles"
description: "Configure OpenID4VP transaction data types for Wallet API v2 using transaction-data-profiles.conf."
stack: "Community Stack (open source) — version 1.1.1"
stack_version: "1.1.1"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/community-stack/wallet2/configurations/config-files/transaction-data-profiles
generated: 2026-10-01
---
# Transaction Data Profiles

`transaction-data-profiles.conf` defines the [OpenID4VP](https://docs.walt.id/concepts/data-exchange-protocols/openid4vp.md) `transaction_data` types Wallet API v2 accepts when previewing, presenting, building, or sending authorization responses.

The `transaction-data-profiles` optional feature is **enabled by default**. When enabled, the wallet:

- Loads type identifiers into its `TransactionDataTypeRegistry`
- Rejects authorization requests that carry unknown `transaction_data.type` values
- Exposes the configured profiles via discovery

## Discovery Endpoint

`GET /transaction-data-profiles`

Returns the configured `List<TransactionDataProfile>` (`type`, `displayName`, `fields`).

Disable the feature (empty registry, no discovery route) by listing it under `disabledFeatures` in [`_features.conf`](https://docs.walt.id/community-stack/wallet2/configurations/config-files/features.md).

**Info:**

**mDoc issuance grant:** For `mso_mdoc` credentials, registering a type here is not enough for the holder to device-sign it. The credential's MSO must authorize that type via `KeyAuthorizations`, which Issuer2 sets from [`authorizedTransactionDataTypes`](https://docs.walt.id/community-stack/issuer2/configurations/config-files/issuer-profiles.md#authorized-transaction-data-types). SD-JWT VC presentations bind transaction data in the KB-JWT and do not use that field.

## File Location

```
waltid-services/waltid-wallet-api2/config/transaction-data-profiles.conf
```

Docker Compose ships the same file under `docker-compose/wallet-api2/config/`.

## Fields

### `transactionDataProfiles`

_Array of Objects_ — List of recognized transaction data types. Each profile defines:

| Field | Type | Description |
|---|---|---|
| `type` | String | **Required.** The transaction data type identifier. Used as the `type` field in transaction data entries and as the namespace for mdoc DeviceSigned binding. |
| `displayName` | String | Human-readable name for UIs and discovery. Defaults to `type` if omitted. |
| `fields` | Array | Expected top-level field names for documentation/UI. Nested payloads (e.g. SCA) can declare a container such as `["payload"]`. |

## Built-in Profiles

```editorconfig[transaction-data-profiles.conf]
transactionDataProfiles = [
  {
    type = "org.waltid.transaction-data.payment-authorization"
    displayName = "Payment Authorization"
    fields = ["merchant_name", "amount", "currency"]
  },
  {
    type = "org.waltid.transaction-data.account-access"
    displayName = "Account Access"
    fields = ["account_identifier", "access_scope"]
  },
  {
    type = "urn:eudi:sca:payment:1"
    displayName = "SCA Payment"
    fields = ["payload"]
  },
  {
    type = "payment_card"
    displayName = "Payment Card"
    fields = ["merchant_name", "amount"]
  }
]
```

Keep Wallet API v2 types aligned with Verifier2 and (for mDocs) Issuer2 `authorizedTransactionDataTypes`. See the shared [Verifier2 transaction-data profiles](https://docs.walt.id/community-stack/verifier2/configurations/config-files/transaction-data-profiles.md) guide for request examples and custom type instructions.

Runtime overlay mutations are not exposed on Community Wallet API v2. Durable types live in `transaction-data-profiles.conf`. Per-service create, replace, and delete live on [Enterprise Wallet2 and Verifier2](https://docs.walt.id/enterprise-stack/setup/configurations/config-files/transaction-data-profiles.md). Wallet API v1 remains discovery-only (`GET /transaction-data-profiles`).

Community Verifier2 session create does not apply a type allowlist. Keep Wallet2 types aligned with the verifier's HOCON so the wallet can present the types a verifier actually requests.