No. Apart from the POS and the HOST, permissions can also be kept in the issuer data.
Say you have made an agreement with a brand and want to offer installments on that brand's cards. If you create a brand permission in the issuer data, you can enable installments only for the BINs in that issuer data. These examples can be multiplied.
You can separate the permissions in the issuer data where you keep credit cards from those in the issuer data where you keep debit cards.
For example, if you want to allow mail order transactions on credit cards but not on debit cards, you can define the permissions differently in the relevant field.
The best-known permissions kept in the issuer data are listed below:
- Mail order permission,
- Brand permission,
- Debit permission,
- Manual entry permission,
- Ask/don't ask for CVV,
- Refund permission; it is possible to add more permissions.
How the permission layers work together
For a transaction to go through, the permission on the POS, the merchant permission on the HOST and the permission tied to the card group must all allow it at the same time. If any of the layers is closed, the transaction is declined.
This structure gives product and risk management teams flexibility: for example, a campaign can be opened only to a specific card group, or a risky transaction type can be closed for one card type.
When a transaction is declined, support teams should check all three layers to find which permission is missing.
