Host Filtering
Definition
Host Filtering is a transaction filtering mechanism that allows you to restrict the use of a payment card based on a specific context.
This filtering can be used to block, authorize, or restrict transactions based on predefined criteria.
Overview
sequenceDiagram
autoNumber
Actor Merchant
Participant Partner
Participant XPO
Note over Partner, XPO: filter creation
Partner -->> XPO: zendesk
XPO -->> Partner: zendesk done
XPO -->> Partner: CardAuthorizationFilterCreatedOrUpdated
Note over Partner, XPO: retrieve filter criteria
Partner -->> XPO: GET /authorization-filters/{filterId}
Note over Merchant, XPO: authorisation OK
rect rgb(236,255,232)
Merchant ->> XPO: authorisation request
XPO ->> XPO: check filters
XPO ->> XPO: check balance
XPO ->> Merchant: authorisation validated
XPO ->> Partner: CardOperationCreatedOrUpdated
end
Note over Merchant, XPO: authorisation KO
rect rgb(255,224,224)
Merchant ->> XPO: authorisation request
XPO ->> XPO: check filters
XPO ->> Merchant: authorisation refused
XPO ->> Partner: CardOperationCreatedOrUpdated {cardAuthorizationDetail.rejectedReason = 'HostFiltering'}
end
Webhook CardAuthorizationFilterCreatedOrUpdated:
https://docs.xpollens.com/reference/post_cardauthorizationfiltercreatedorupdated
In the future, if the authorisation is refused because of the host filtering, the attribute will be populated with the ID of the filter that caused the rejection.
Technical aspects
Filters are created by card offer.
Arithmetic Comparison Operators
A closed-loop filter must support comparisons between a field and an authorization value using the following operators:
-
EqualsTo
-
DifferentThan
-
GreaterThan
-
GreaterThanOrEqualsTo
-
LowerThan
-
LowerThanOrEqualsTo
Logical Operators
A closed-loop filter must support comparisons between filters using logical combinations:
- And
- Or
Filtering criteria
One or more of the following criteria:
- SIRET
- MerchantId
- BinAcquereur
- MCC
Filter Structure
A closed-loop filter can be standalone or part of a set of multiple filters.
Nesting of filters (sub-filters) should be supported up to 3 levels deep
Example
{
"cardAuthorizationFilterId": "MyFilter1",
"IsEnabled": true,
"Filter" :
{
"Type": "Composite",
"LogicalOperator": "Or",
"Filters" : [
{ "Type": "Comparison", "Category": "Siret", "AritmeticOperator": "EqualsTo", "Value" : "57206259400062" },
{
"Type": "Composite",
"LogicalOperator": "And",
"Filters" : [
{ "Type": "Comparison", "Category": "MerchantId", "AritmeticOperator": "EqualsTo", "Value" : "2035130" },
{ "Type": "Comparison", "Category": "BinAcquereur", "AritmeticOperator": "EqualsTo", "Value" : "497200" }
]
}
]
}
}Manage filter
Retrieve existing filters
Use the GET.
Create, modify or delete a filter
Open a zendesk ticket with your demands.
How to tests
1- With the help of your Customer Integration Manager, create the desired filters.
2- Use the authorisation simulator to create a transaction to generate the alert.
Updated 6 months ago