Payment Account Reference (PAR)

Use PAR to recognise payment activity linked to the same underlying payment account.

Introduction

Payment Account Reference (PAR) is a non-financial identifier defined by EMVCo and assigned by the card schemes to a Primary Account Number (PAN). It helps you recognise related transactions made with the same payment account using different payment instruments.

PAR may be returned for supported card scheme transactions when it is provided by the card scheme and passed through by the acquirer. This can include payments made with physical cards, gateway tokens, and scheme tokens. When these payment instruments are linked to the same payment account, the card scheme may return the same PAR value.

PAR is returned for information purposes only. It is not a payment credential and cannot be used to authorise, capture, refund, or otherwise initiate a transaction.

How PAR works

A PAR value is assigned to a PAN by the card scheme and is not generated or modified by emerchantpay. When a transaction is processed, the card scheme may return the PAR value. You may find this value in payment responses, API notifications, WPF notifications, and Reconcile API responses when it is available. See Receiving PAR for details.

A PAR value contains 29 alphanumeric characters. For example: V0010013021763880207087508533.

COMPONENT	LENGTH	DESCRIPTION
BIN Controller Identifier	4 characters	Identifies the BIN controller context.
Unique reference value	25 characters	Identifies the payment account reference.

A customer may pay with a physical card, a card stored in a digital wallet such as Apple Pay or Google Pay, a gateway token, or a scheme token. These instruments may have different identifiers, but the same PAR can be returned when they are linked to the same PAN.

This makes PAR especially useful when you accept tokenised payments. Tokenisation replaces the PAN with a token, which improves security but can make same-account transactions harder to recognise.

PAR gives you a stable account-level reference for use cases such as reporting, loyalty, reconciliation, risk analysis, and fraud prevention, without exposing or storing sensitive card data.

Keep the following in mind:

PAR is not a PAN and must not be treated as a payment credential.
PAR does not replace existing transaction identifiers such as unique_id, transaction_id, or scheme transaction identifiers.

Warning: Do not build your integration so that it depends on PAR always being present. The field may be empty or omitted because PAR is returned only when the card scheme provides it and it is passed on through the acquirer.

Reissued cards

For recurring payments, PAR can also help you recognise follow-up transactions when visible card details change. When a card is reissued, the PAR value can remain the same if the issuer provides the relevant lifecycle management update. This means the PAR value may continue to link the old card, the new card, and associated tokens to the same payment account.

PAR continuity depends on the issuer and scheme providing the relevant lifecycle update. Do not assume that PAR will always be present or unchanged in every card reissue scenario.

When to use PAR

Use PAR when you need to recognise payment activity linked to the same underlying payment account without using the PAN.

PAR can support the following use cases:

USE CASE	DESCRIPTION
Loyalty	Link purchases made with the same payment account to a loyalty benefit or campaign.
Reporting	Group transactions that belong to the same payment account.
Fraud analysis	Identify repeated risky behaviour associated with the same payment account.
Reconciliation	Improve account-level transaction matching across card and tokenised payments.
Customer insights	Understand payment activity across multiple channels or shops.
Card lifecycle continuity	Recognise payment activity after a card is reissued, where PAR remains available.

Do not use PAR as:

DO NOT USE AS	REASON
A payment credential	PAR cannot be used to process or authorise payments.
A replacement for a token	PAR is not a transaction-capable token.
A customer identity	PAR identifies a payment account, not a person.
A guarantee of ownership	More than one person may use the same payment account.
The sole basis for a fraud decision	PAR should be one signal within a broader risk strategy.
A required field for transaction acceptance	PAR may not be available for every transaction.

Receiving PAR

When PAR is available for a transaction, emerchantpay may return it through the following response and notification flows:

Payment transaction responses
API notifications
WPF notifications
Reconcile API responses

Each section below explains where the PAR field is returned and shows an example response or notification.

Receiving PAR in payment transaction responses

In payment transaction responses, PAR may be returned in the payment_account_reference field.

Response example:

<payment_response>
    <transaction_type>sale</transaction_type>
    <status>approved</status>
    <mode>live</mode>
    <transaction_id>119643250547501c79d8295</transaction_id>
    <unique_id>44177a21403427eb96664a6d7e5d5d48</unique_id>
    <technical_message>Transaction successful!</technical_message>
    <message>Transaction successful!</message>
    <timestamp>2024-10-08T13:53:06Z</timestamp>
    <descriptor>Descriptor one</descriptor>
    <amount>1000</amount>
    <currency>EUR</currency>
    <sent_to_acquirer>true</sent_to_acquirer>
    <payment_account_reference>V00100130217638802070875085</payment_account_reference>
</payment_response>

Receiving PAR in notifications

In API notifications, PAR may be returned in the payment_account_reference field.

Notification example:

“transaction_id”: “119643250547501c79d8295”
“terminal_token”: “871bbbd2f9ce1d58dead9848ef5a24ab59a8ee94”
“unique_id”: “44177a21403427eb96664a6d7e5d5d48”
“transaction_type”: “sale”
“status”: “approved”
“signature”: “b74ed54d95589fce6f9d7a229b225fd4a925e9bc”
“amount”: “1000”
“currency”: “EUR”
“payment_account_reference”: “V00100130217638802070875085”

For the full list of notification fields, see the Notifications API reference.

Receiving PAR in WPF notifications

For WPF card payments, including digital wallet payments, PAR may be returned in the payment_account_reference field.

WPF notification example:

signature=c5219b3d385e74496b2b48a5497b347e102849f10eacd25b062f823b
&payment_transaction_transaction_type=sale3d
&payment_transaction_terminal_token=e9fd7a957845450fb7ab9dccb498b6e1f6e1e3aa
&payment_transaction_unique_id=bad08183a9ec545daf0f24c48361aa10
&payment_transaction_amount=500
&payment_transaction_currency=EUR
&payment_account_reference=V0010013021763880207087508533
&wpf_transaction_id=mtid201104081447161135536962
&wpf_status=approved
&wpf_unique_id=26aa150ee68b1b2d6758a0e6c44fce4c

For the full list of notification fields, see the WPF notifications API reference.

Receiving PAR in reconciliation API responses

In Reconciliation API responses, PAR may be returned in the payment_account_reference field.

Reconciliation API response example:

<payment_response>
  <transaction_type>sale</transaction_type>
  <status>approved</status>
  <authorization_code>005645</authorization_code>
  <retrieval_reference_number>016813015184</retrieval_reference_number>
  <payment_account_reference>V00100130217638802070875085</payment_account_reference>
  <response_code>00</response_code>
  <unique_id>44177a21403427eb96664a6d7e5d5d48</unique_id>
  <transaction_id>119643250547501c79d8295</transaction_id>
  <mode>live</mode>
  <timestamp>2026-05-28T07:35:37Z</timestamp>
  <descriptor>Descriptor one</descriptor>
  <amount>9000</amount>
  <currency>USD</currency>
  <card_brand>visa</card_brand>
  <card_number>420000…0000</card_number>
  <card_type>CREDIT</card_type>
  <sent_to_acquirer>true</sent_to_acquirer>
  <arn>74537605259536043849425</arn>
  <scheme_response_code>00</scheme_response_code>
  <technical_message>Transaction successful!</technical_message>
  <message>Transaction successful!</message>
</payment_response>

For the full list of response fields, see the Reconcile API reference.

Was this page helpful?