The purpose of the “whitelist” is to make the application of a transaction acceptance rule selective. It becomes inoperative for identified customers, VIPs, or trusted customers who are included in a “whitelist”. “Whitelists” apply to customer-specific data, such as their bank card number or IP address. This feature makes it possible to be less restrictive for certain user populations. <\/li>\n\n\n\n
The “blacklist” service makes it possible to refuse payments. As with “whitelists”, “blacklists” apply to data specific to the cardholder (card, IP, phone, email). <\/li>\n\n\n\n
This tool makes it possible to build the specific rules that define the conditions for accepting a payment.<\/li>\n\n\n\n
The scoring service detects potentially fraudulent transactions based on cross-analysis of multiple payment-related data points.<\/li>\n<\/ul>\n\n
The transaction processing phases are always executed in this order.<\/p>\n\n
If the input data meets all the conditions of the defined “whitelist”, the “blacklist” service will not be executed and the transaction will be processed normally.<\/p>\n\n
If the input data meets one of the conditions of the defined “blacklist” and is not included in the “whitelist” service, the transaction will be refused and the “acceptance rule” service will not be executed. Each service is executed top-down with respect to the CentralPay actor hierarchy, which means that a platform can apply its anti-fraud service settings to its merchants, but the reverse is not possible. <\/p>\n\n
2. Fraud scoring tool<\/h2>\n\n
CentralPay relies on a fraud detection service based on machine learning algorithms.<\/p>\n\n
This predictive engine is built from a large sample of data provided by CentralPay in JSON format and sourced from This service relies on behavioral classification linked to the merchant\u2019s business sector.<\/p>\n\n The engine returns an action and a score. The action instructs the payment service to accept or refuse the transaction. <\/p>\n\n The score classifies the risk level by providing a percentage probability of fraud. This score is then interpreted in the rules engine. <\/p>\n\n The score enables the merchant and the algorithm to interact together to improve.<\/p>\n\n Scores are classified as follows: <\/p>\n\n This fraud exposure analysis service analyzes the fraud risk exposure context of each transaction. This service returns a score that makes it possible to automatically process the expected response in the rules engine. <\/p>\n\n The score is based on cross-analysis of the following data:<\/p>\n\n The purpose of the “whitelist” is to make the application of an acceptance rule selective. This rule becomes inoperative for identified customers, VIPs, or trusted customers who are included in a “whitelist”. <\/p>\n\n The anti-fraud service then moves on to the next step.<\/p>\n\n “Whitelists” apply to customer-specific data, such as their bank card number or IP address. This feature makes it possible to be less restrictive for a user population. <\/p>\n\n The “blacklist” step makes it possible to refuse payments.<\/p>\n\n As with “whitelists”, “blacklists” apply to data specific to the cardholder:<\/p>\n\n The acceptance rules engine is a powerful, modular application component that makes it possible to adapt the processing behavior to be applied to each transaction, such as:<\/p>\n\n This service therefore makes it possible to define actions to be performed on each transaction from a wide list of available attributes: fraud score, cardholder location, total sales amount over 7 or 30 days, VIP whitelist customer, specific parameter provided by the merchant\u2026<\/em><\/p>\n\n An acceptance rule is a logical condition. It makes it possible to authorize, restrict, and\/or prohibit transactions. The syntax of a rule is as follows: “Action” “if” “Attribute” “Comparison operator” “Comparison value”<\/p>\n\n Example:<\/strong><\/p>\n\n The rule shown in this example makes it possible to automatically refuse payments when the card country is not France. By typing “#”, the available attributes are displayed.<\/p>\n\n In a rule, an attribute is always followed by a comparison operator.<\/p>\n\n List of attributes<\/strong>:<\/p>\n\n In the case of custom_acceptance_data[‘key’] = ‘value’, for it to be taken into account, the exact same field must be included in the request for the targeted object.<\/p>\n\n Logical operators and parentheses:<\/strong><\/p>\n\n Logical operators AND and OR<\/span><\/p>\n\n The syntax used to define rules makes it possible to create multiple conditions within the same rule. The conditions will remain defined in the same way, with the only difference being that a keyword will be placed between the conditions. <\/p>\n\n The keywords are and and or. They define how the rules engine will interpret the sequence of these rules. “AND” corresponds to inclusion and “OR” to exclusion. <\/p>\n\n Example:<\/strong><\/p>\n\n The previous example allows payments whose amount is less than 10 AND<\/strong> whose card is French. If one or the other of the defined conditions is not met, the action will not be executed. <\/p>\n\n Example:<\/strong><\/p>\n\n The previous example allows payments whose amount is less than 10 OR<\/strong> whose card is French. If one or the other of the defined conditions is met, the action will be executed. <\/p>\n\n Parentheses<\/span><\/p>\n\n Using parentheses when defining a multi-condition rule makes it possible to define condition blocks and the priorities between these blocks. The principle is the same as for priorities in mathematical operators. <\/p>\n\n Example:<\/strong><\/p>\n\n In the previous example, the rules engine will first interpret the block (#card_country = ‘FRA’ or #currency = ‘EUR’). That is, the payment will be allowed if (the card is French or the currency is the euro), AND the amount is less than 10. <\/p>\n\n Rule execution order<\/span><\/p>\n\n Rules are executed in an order to be defined. This order is important because as soon as a transaction meets the criteria of a rule, the following rules will not be processed. <\/p>\n\n Rules are executed in the display order of the list in the interface. Rule examples:<\/strong><\/p>\n\n This example allows transactions whose amount is less than 10 if the sum of the day\u2019s transaction amounts is less than 100.<\/p>\n\n This rule blocks payments if the risk score exceeds 3 or if the IP used and the card issuing region correspond to the ‘ASIA_PACIFIC’ zone.<\/p>\n\n This rule requires a 3D Secure transaction if the card country is not France, the United States, or Great Britain.<\/p>\n\n This previous example ALLOWS payments IF the amount is LESS THAN 100 AND the sum of the day\u2019s transaction amounts is LESS THAN 1000 OR the currency is \u20ac or $ AND the sum of the month\u2019s transaction amounts is LESS THAN 10,000.<\/p>\n\n The logical operators “AND” and “OR” are only syntactically correct in lowercase.<\/p>\n\n The comparison operators = , != , > , < , >= and <= must be followed by a value.<\/p>\n\n The IN and NOT IN operators are followed by a list of comparison values. Example:<\/strong><\/p>\n\n The example shown above makes it possible to refuse all payments whose currency is not the Euro, the US Dollar, the Pound Sterling, or the Swiss Franc.<\/p>\n\n This syntax avoids writing multiple rules or multiple conditions within the same rule.<\/p>\n\n Depending on the value type, the syntax used to define the value will not be the same:<\/p>\n\n The available operators are AND and OR. They define how the rules engine will interpret the sequence of these rules. “AND” enables inclusion, while “OR” enables exclusion. <\/p>\n\n Example:<\/strong><\/p>\n\n The example shown above makes it possible to refuse payments whose amount is less than \u20ac10 AND whose card is not French. If one or the other of the defined conditions is not met, the action will not be executed. <\/p>\n\n 1. Organization of anti-fraud services Anti-fraud services are segmented into 4 tools: The transaction processing phases are always executed in this order. If the input data meets all the conditions of the defined “whitelist”, the “blacklist” service will not be executed and the transaction will be processed normally. If the input data meets one of […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":16299,"menu_order":2,"comment_status":"open","ping_status":"closed","template":"","doc_tag":[],"doc_badge":[],"class_list":["post-16304","docs","type-docs","status-publish","hentry","no-post-thumbnail"],"acf":[],"yoast_head":"\ntransaction<\/code>, refund<\/code>, dispute<\/code> data.<\/p>\n\n\n
Transaction accepted
No action<\/li>\n\n\n\n
Transaction accepted
Action: Send an event with score details for manual review and learning<\/li>\n\n\n\n
Transaction refused
Action: Send an event with score details for manual review and learning<\/li>\n<\/ul>\n\n\n
3. Whitelists and blacklists<\/h2>\n\n
3.1. Whitelist<\/h3>\n\n
3.2. Blacklist<\/h3>\n\n
\n
4. Transaction acceptance rules<\/h2>\n\n
\n
A rule consists of 4 elements: the action, the attributes, the operators, the values. <\/p>\n\nREFUSE if card_country != 'FRA'<\/code><\/pre>\n\n
The grammar syntax chosen by the platform for its acceptance engine is very similar to SQL syntax (used to interact with databases).<\/p>\n\n4.1. Available actions<\/h3>\n\n
\n
Allows the payment<\/li>\n\n\n\n
Refuses the payment<\/li>\n\n\n\n
Sends a “webhook” notification for the associated transaction<\/li>\n<\/ul>\n\n4.2. Available attributes<\/h3>\n\n
Attribute<\/th> Description<\/th> Value type<\/th> Example<\/th><\/tr><\/thead> #always<\/strong><\/td> <\/td> None<\/td> <\/td><\/tr> #transactions[_\u00e9tat][_entit\u00e9] [_temporalit\u00e9]<\/strong><\/td> Transaction count quota [state] [entity] [time period]<\/td> Integers<\/td> <\/td><\/tr> #transactions_amount[_\u00e9tat] [_entit\u00e9][_temporalit\u00e9]<\/strong><\/td> Transaction amount quota [state] [entity] [time period]<\/td> Integers<\/td> <\/td><\/tr> #amount<\/strong><\/td> Transaction amount in cents<\/td> Integer<\/td> #amount > 100<\/td><\/tr> #card_country<\/strong><\/td> Card issuing country<\/td> String
ISO 3166-1 alpha-3<\/td>#card_country IN (‘FRA’, ‘USA’, ‘BEL’, ‘DEU’)<\/td><\/tr> #card_establishment<\/strong><\/td> Card issuer<\/td> <\/td> <\/td><\/tr> #card_product<\/strong><\/td> Card type<\/td> ‘gold’, ‘platinium’<\/td> <\/td><\/tr> #card_product_type<\/strong><\/td> Card type (personal or corporate)<\/td> CONSUMER CORPORATE<\/td> #card_product_type = ‘CONSUMER’<\/td><\/tr> #card_region<\/strong><\/td> Card issuing region<\/td> ‘ASIA_PACIFIC”EUROPE”LATIN_AMERICA”MIDDLE_EAST_AND_AFRICA”USA_AND_CANADA”ANTARCTIQUE”UNKNOWN’<\/td> #card_region NOT IN (‘ASIA_PACIFIC’, ‘LATIN_AMERICA’)<\/td><\/tr> #commercial_brand<\/strong><\/td> Card brand<\/td> VISA MASTERCARD AMEX OTHER<\/td> #commercial_brand != ‘VISA’<\/td><\/tr> #currency<\/strong><\/td> Transaction currency<\/td> String
ISO 4217<\/td>#currency = ‘EUR’<\/td><\/tr> #ip_country<\/strong><\/td> IP address country<\/td> String
ISO 3166-1 alpha-3<\/td>#ip_country IN (‘FRA’, ‘USA’, ‘BEL’, ‘DEU’)<\/td><\/tr> #ip_region<\/strong><\/td> IP address region<\/td> ‘ASIA_PACIFIC”EUROPE”LATIN_AMERICA”MIDDLE_EAST_AND_AFRICA”USA_AND_CANADA”ANTARCTIQUE”UNKNOWN’<\/td> #card_region NOT IN (‘ASIA_PACIFIC’, ‘LATIN_AMERICA’)<\/td><\/tr> #is_anonymous_ip<\/strong><\/td> Is an anonymous IP<\/td> TRUE | FALSE<\/td> #is_anonymous_ip = TRUE<\/td><\/tr> #is_three_d_secure<\/strong><\/td> Is a 3D-Secure transaction<\/td> TRUE | FALSE<\/td> #is_three_d_secure = TRUE<\/td><\/tr> #payout_amount<\/strong><\/td> Payout amount<\/td> Integer<\/td> #payout_amount > 100<\/td><\/tr> #payout_currency<\/strong><\/td> Payout currency<\/td> String
ISO 4217<\/td>#payout_currency = ‘EUR’<\/td><\/tr> #risk_score<\/strong><\/td> Anti-fraud score<\/td> Double<\/td> #risk_score > 2,34<\/td><\/tr> #custom_acceptance_data[‘key’] = ‘value’<\/strong><\/td> custom field<\/td> key : Regex [a-zA-Z0-9_-]value: Regex [a-zA-Z0-9_-]<\/td> #custom_acceptance_data[‘product_category’] = ‘high’<\/td><\/tr><\/tbody><\/table><\/figure>\n\n ALLOW if<\/strong> #amount < 1000 and #card_country = 'FRA'<\/code><\/pre>\n\nALLOW if<\/strong> #amount < 1000 or #card_country = 'FRA'<\/code><\/pre>\n\nALLOW if<\/strong> #amount < 1000 and (#card_country = 'FRA' or #currency = 'EUR')<\/code><\/pre>\n\n
A position indicator is displayed in each list. To change a rule\u2019s position, simply drag it to the desired position. <\/p>\n\n![\"\"](\"https:\/\/docs.centralpay.com\/wp-content\/uploads\/2023\/07\/ordre-regles.png\")
<\/figure>\n\nALLOW if<\/strong> #amount < 1000 and #transactions_amount_daily < 10000<\/code><\/pre>\n\nREFUSE if<\/strong> #risk_score > 3 or (#ip_regions = 'ASIA_PACIFIC' and #card_region = 'ASIA_ PACIFIC')<\/code><\/pre>\n\nTHREE_D_SECURE if<\/strong> #card_country NOT IN ('FRA', 'USA', 'GBR') <\/code><\/pre>\n\nALLOW (#amount < 10000 and<\/strong> #transactions_amount_daily < 100000) or (#currency IN ('EUR', 'USD') and #transactions_amount_monthly < 1000000)<\/code><\/pre>\n\n4.3. Available comparison operators<\/h3>\n\n
\n
A list of values is enclosed in parentheses, and the values inside the list are separated by commas.<\/p>\n\nREFUSE if #currency NOT IN ('EUR', 'USD', 'GBP', 'CHF')<\/code><\/pre>\n\n4.4. Available values:<\/h3>\n\n
\n
\u2139\ufe0f \"Amount\" values must be provided in cents (e.g., for \u20ac10 you would provide a value of 1000).<\/pre>\n\n
4.5. Logical operators:<\/h3>\n\n
REFUSE if #amount < 1000 and #card_country != 'FRA'<\/code><\/pre>\n\n