Single, Batch, and Multiple Issuance

Procivis One enables you to receive single credentials, credentials issued as part of a batch, and multiple credentials in one issuance flow. The wallet also groups credentials that represent the same underlying credential when it is issued in more than one format. This page explains how these types differ, and how the wallet decides whether credentials get grouped together.

Single credentials

A single credential is issued once. The wallet then reuses this credential across multiple presentations. In the list and detail credential endpoints, these credentials appear as "type": "SINGLE".

Batch credentials

Multiple credentials are issued at once. When you receive a batch credential the system creates a batch parent — a logical record that tracks and manages the batch — along with the individual batch items themselves, which are the credentials actually issued and presented. In the list and detail credential endpoints, these appear as "type": "BATCH_PARENT" and "type": "BATCH_ITEM". The wallet automatically generates a unique holder-binding key for each batch item.

A batch parent is created when either:

• the issuer offers more than one credential (a batch size greater than 1), or
• the issuer offers a single credential, or omits batch-size metadata, but the credential has an expiry date and a refresh token is available

The second condition exists because an expiry date plus a refresh token together mean the credential can be renewed later — the wallet groups it as a batch so future refreshes stay connected to it, rather than treating it as a one-off credential.

note

If you specify an identifier when accepting the offer instead of letting the system auto-generate one, the system will not bind multiple credentials from an offered batch. It binds a single credential to that identifier instead, since there's no benefit to holding multiple copies against the same identifier.

When you use the batch parent for submitting presentations, the Core automatically chooses the oldest (unused) batch item closest to expiration. Once presented, the system updates the credential's consumedAt field, found in the credential detail endpoint, and then never uses that credential again.

Batch check and refresh

Use:

• POST /api/credential/v1/revocation-check to check status and
• POST /api/interaction/v1/{interactionId}/issuance/refresh to request a new batch of credentials from the issuer

New batch items are automatically connected to the original batch parent.

Multiple credentials issuance

When an issuer offers multiple credentials in one issuance flow, POST /api/interaction/v1/issuance-accept iterates through all offered configurations and accepts all supported configurations, returning the resulting credentials in the credentialIds array.

If any configuration is not supported it is skipped, a warning is logged, and partiallySuccessful is returned true. If no configuration is supported, the call fails. Configurations can be skipped for different reasons:

• No format provider enabled matching the format of the offer
• Format string is unknown
• Identifier or key offered does not match the configuration

Multi-format issuance and credential grouping

When the same credential is offered in more than one format within a single issuance — for example, both SD-JWT VC and mdoc — the wallet tries to recognize them as the same underlying credential and group them together, so you do not end up with a separate wallet entry per format. Grouped credentials use the same batch parent / batch item model described above: the different formats become BATCH_ITEMs under a shared BATCH_PARENT, following the same batch parent conditions — the group only forms if the offer's batch size is greater than 1, or the credentials have an expiry date and a refresh token available. Otherwise each format is issued as its own separate SINGLE credential.

Credentials can only be grouped this way if the wallet first determines they share the same credential schema.

How the wallet matches schemas

• Same ecosystem schema ID: the wallet treats the credentials as the same schema.

  • If the incoming credential has claim differences that do not conflict with what the wallet already knows — for example, a few additional optional claims — the wallet updates its existing schema record to include them.
  • If the differences conflict with what the wallet expects — a claim the wallet considers required is missing, or the incoming credential changes whether a claim is required — acceptance of that credential fails.

• No ecosystem schema ID, or different IDs: the wallet looks for an existing schema to group with, checking, in order:

  1. The credential schema name matches exactly.

  2. The claim translation names match in at least one language, even if the underlying technical claim keys differ.

  3. The required flag on those claims matches.

  If all of these match, the wallet groups the credentials as the same schema, even without a shared ecosystem schema ID.

Two credentials of the same format with different ecosystem schema IDs are always treated as different credentials. This matching logic is only for reconciling different formats of what is otherwise the same credential — it never merges same-format credentials that simply have different translations.

Scope of grouping

Grouping happens per issuance. When you accept an issuance, the wallet groups whatever it can within that single "handle invitation" interaction; credentials from separate issuance interactions are never grouped together, even where the schema would otherwise match. Once a batch parent is formed, any future refresh (see Batch check and refresh) stays within that same group.

note

If you specify an identifier instead of letting the system auto-pick, the wallet still requests one credential per offered format and binds all of them to that identifier. Whether they are then grouped into a batch parent still depends on the expiry-date/refresh-token condition above.

Rejecting grouped credentials

After accepting an issuance, you can reject at a more granular level than rejecting the offer as a whole. With grouped or batch credentials, you can reject:

• a single, ungrouped credential — the issuer is notified, and the interaction cannot be continued (no further refresh)
• all items of a particular format — has the same effect, and shuts that format off entirely
• a single batch item — equivalent to marking that item consumed; only that item is removed