PCI and Non-PCI Payment Processing
Orkestral receives a payment request, identifies the payment method, applies the active flow, and routes the transaction to the appropriate Payment Service Provider (PSP).
The path depends on whether card data is involved:
- in the PCI scenario, the transaction uses credit or debit card data;
- in the Non-PCI scenario, the payment does not use the card number (PAN) or other sensitive card data.
Before you start
For a payment to be processed:
- the PSP must be contracted, active, and configured;
- an active flow must exist for the payment method;
- the PSP credentials must be valid;
- the PSP must support the transaction's country, currency, and payment method.
The active flow defines the primary PSP and any configured alternative PSPs. If there is no active flow or compatible PSP, the payment cannot be processed.
Comparing the scenarios
| Characteristic | PCI | Non-PCI |
|---|---|---|
| Common methods | Credit and debit cards | PIX, bank slip, transfer, and digital wallets |
| Card data | Uses protected card data | Does not use PAN, expiration date, or security code |
| Submission methods | Data for immediate use or a token | Data specific to the payment method |
| Card token | Can be created and reused | Not applicable |
| PSP selection | Defined by the active flow | Defined by the active flow |
| Result | Initial response and possible later updates | Initial response and possible later updates |
Non-PCI flow
The Non-PCI scenario is used when the transaction does not need to transport or process card data.
[ Client ] ──► [ Orkestral ] ──► [ Active flow ] ──► [ PSP ]
│ │
└───────── [ Result ] ◄────────────────┘
How it works
- The client sends transaction data such as the amount, currency, payment method, and information required by the selected method;
- Orkestral validates the data and records the transaction;
- The active flow evaluates its configured conditions;
- The platform selects the PSP for the resulting path;
- The request is adapted to the format expected by the PSP;
- The PSP processes the payment and returns the result;
- Orkestral updates the transaction and returns the response to the client.
The PSP can also send a later update, for example, when an initiated payment still requires confirmation.
PCI flow without a token
In this scenario, card data is provided for the current payment without retrieving a previously saved card.
[ Checkout or SDK ] ──► [ Secure processing ]
│
▼
[ Active flow ] ──► [ PSP ]
│ │
└── [ Result ] ◄─┘
How it works
- The cardholder enters the card data in an integrated checkout or SDK;
- The data is transmitted over a secure channel;
- Orkestral validates the information required for the payment;
- The transaction is created and the active flow selects the PSP;
- The data is sent to the PSP only to process the authorization;
- The PSP returns the result;
- Orkestral updates the transaction and returns the response to the client.
Never send real card data through logs, messages, URLs, support tools, or test environments. Card data must only be captured by approved integration components.
PCI flow with a token
A token represents a securely stored card. It allows new payments to be initiated without the client submitting the full card number again.
[ Client + token ] ──► [ Temporary secure retrieval ]
│
▼
[ Active flow ] ──► [ PSP ]
│ │
└── [ Result ] ◄─┘
Storing the card
- The cardholder enters the card data in the checkout or SDK;
- The integration submits the data to the secure tokenization process;
- Persisted information is encrypted;
- The platform records only the token reference and masked metadata, such as the last digits and card brand;
- The token is returned for use in future payments.
Paying with the token
- The client sends the token with the new transaction data;
- Orkestral validates the association between the token and the client;
- The required data is retrieved temporarily within the protected environment;
- The active flow selects the PSP;
- The payment is sent to the PSP;
- After processing, the retrieved data is not included in the response, events, or notifications.
Removing the token
When a saved card should no longer be used, the client requests its removal. The reference is invalidated and the related protected object is removed, preventing new payments with that token.
The card security code, also known as CVV, CVC, or PIN depending on the PSP, is not stored with the token.
Primary and alternative PSPs
PCI and Non-PCI scenarios use the same routing principle. The platform tries the primary PSP defined by the active flow. If it cannot process the transaction and alternatives are configured, the next option is tried in the defined order.
[ Active flow ] ──► [ Primary PSP ] ──failure──► [ Alternative PSP ]
│ │
success success
│ │
└──────────► [ Result ] ◄──────┘
A valid decline from the issuer or PSP does not necessarily cause another provider to be tried. An alternative attempt depends on the nature of the failure and the applicable processing rules.
Responsibilities
| Participant | Main responsibilities |
|---|---|
| Client | Use approved components, protect credentials, and avoid storing or logging sensitive data received during the integration |
| Orkestral | Validate and route the transaction, protect data in transit and at rest, restrict access, and keep sensitive data out of logs and events |
| PSP | Authorize or decline the payment, protect received data, and report the result or later updates |
Data protection
During the PCI scenario:
- communication takes place over HTTPS;
- persisted card data is encrypted;
- access to protected content is restricted to authorized components;
- references and metadata use masked information;
- sensitive data must not appear in logs, events, or notifications;
- development and test environments must not use real cards.
These controls help protect cardholder data and keep the environment aligned with applicable PCI DSS requirements.
Results and updates
The first response contains the result available at that time. Depending on the payment method and PSP, the status can change later.
| Situation | What happens |
|---|---|
| Approved payment | The transaction is updated with the identifier and status returned by the PSP |
| Pending payment | The transaction waits for later confirmation from the PSP |
| Declined payment | The response states that the payment was not authorized |
| Technical failure | The platform can try an alternative PSP when the flow and type of failure allow it |
| Later update | A webhook or event updates the transaction status |
Best practices
- Prefer tokens for recurring payments or saved cards;
- Do not store PAN or security codes in your application;
- Do not include sensitive data in logs or error messages;
- Validate webhooks before updating the order status;
- Use transaction identifiers for reconciliation and support;
- Test only with the cards and environments provided for that purpose;
- Keep an active flow and alternative PSPs when your operating model requires greater availability.
Frequently asked questions
What is the difference between PCI and Non-PCI?
The PCI scenario processes credit or debit card data. Non-PCI processes methods that do not use this data, such as PIX, bank slips, and transfers.
Do I have to save the card to make a PCI payment?
No. The payment can use the data only for the current transaction. A token is only needed when the card must be referenced again.
Does the token contain the full card number?
No. It works as an opaque reference to data held in the protected environment.
Does Orkestral store the security code?
No. The security code is used only when required for processing and is not persisted with the token.
What happens if the token is invalid or has been removed?
The payment is not sent to the PSP. The client must use another valid token or submit the card data again through an approved component.
Is a payment result always final?
No. Some payment methods and PSPs return an initial status and send the final confirmation later.