# High priority vs normal priority payments

A payment can be **high priority** when the use case requires near-instant confirmation of rejection, for example when paying in-store, or **normal priority**, for example when using Nexus for P2P or bill payments.

Whether a payment is high priority or not is flagged using the `pacs.008` Instruction Priority element(`/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/`).

In general the Source PSP should set the Instruction Priority, based on what it knows about the type of payment that is being initiated. For example, payments to a retail business, or initiated by scanning a QR code, are more likely to be time sensitive. If the Sender is asked to select the priority, they should be informed of the implications of their choice.

## High priority payments <a href="#toc163731059" id="toc163731059"></a>

High priority payments must only be accepted by the Destination IPS if the Destination IPS has made the final clearing and settlement of the transaction subject to a pacs.002 confirmation message from Nexus.

* The Source PSP should set the `pacs.008` Instruction Priority to **HIGH**
* Within the timeout SLA of the Destination IPS, the Destination PSP must process the payment and return a `pacs.002` with one of the following status codes:
  * **`ACCC`** – accepted and credited to recipient
  * **`RJCT`** – rejected
  * **`BLCK`** - funds blocked and will not be returned (due to suspicious or illicit activity)
* The Destination IPS must forward the `pacs.002`  to Nexus with the timeout SLA. Nexus will confirm receipt with a confirmation `pacs.002` back to the Destination IPS. This allows the Destination IPS to finalize clearing and confirm to the Destination SAP and Destination PSP.
* In the scenario the Destination IPS does not receive a `pacs.002`  from the Destination PSP before the timeout SLA, the Destination IPS must cancel the payment and send a negative `pacs.002` Nexus, rejecting the transaction.
* The `pacs.002` will be forwarded to the Source IPS by Nexus to finalize the clearing in the Source country.
* In the scenario Nexus does not receive a `pacs.002`  from the Destination IPS before the timeout SLA, Nexus will send a negative `pacs.002`  to the Destination IPS and the Source IPS, rejecting the transaction.
* (Note: The Source SAP may only respond with ACCC or RJCT.)

## Normal priority payments <a href="#toc163731060" id="toc163731060"></a>

* The Source PSP should set the pacs.008 Instruction Priority to **NORM** (`pacs.008` element `/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/` ) when the payment is not urgent.
* Within the technical timeout SLA of the Destination IPS, the Destination PSP must process the payment and send back a `pacs.002` with one of the following status codes:
  * **`ACCC`** – accepted and credited to recipient
  * **`RJCT`** – rejected
  * **`BLCK`** – funds blocked and will not be returned (due to suspicious or illicit activity)
* The Destination IPS must forward the `pacs.002`  to Nexus with the timeout SLA. Nexus will confirm receipt with a confirmation `pacs.002` back to the Destination IPS.&#x20;
* The `pacs.002` will flow from the Destination PSP to Destination IPS, to Nexus, to the Source IPS and finally to the Source PSP.
* In the scenario Nexus does not receive a `pacs.002`  from the Destination IPS before the timeout SLA, Nexus will wait until the `pacs.002`  is received, or a resend is requested by the Source PSP (through a resend of the original pacs.008, see [Investigations](https://docs.nexusglobalpayments.org/payment-processing/unsuccessful-payments-exceptions/investigation-and-enquiry)).
* (Note: The Source SAP may only respond with ACCC or RJCT.)