Payment Scoring
After a (card) payment was initiated with and validated by PXP, before the authorisation is done with the Provider/Schemes, a payment scoring phase is done.
In this scoring phase, a configured set of payment scoring checks is executed to decide if a payment should be approved, blocked or refused.
Each payment scoring check compares certain values and if the result is true, it give a configured score. After each check was executed, the system sums up all scores and calculates the total score.
Then, this total score is compared against a configured threshold for this type of payment and other combinations.
If the total score is
- below the threshold, then the payment is automatically approved.
- above the threshold, then, depending on the configuration (payment method etc.), the payment will be blocked or refused.
The decision which scoring checks have to/should be executed during the payment scoring phase of a certain type of payment is done by two parties:
- The PXP Financial risk team
- The merchant
The PXP Financial risk team decides which scoring checks have to be executed to fulfil the necessary legal/compliance/risk requirements.
The merchant can ask for additional risk checks to be configured via the Support Team or the regarding Account manager.
The below table provides an overview about the most important scoring checks and a short description:
| Check Category | Description | Example Scoring Checks |
|---|---|---|
| Limit Checks | Limit checks can be used to establish limitations for payments (based on amount or count) for periods like 24h, 72h or 30 days. This is mainly used in the gaming business. | 24h Same Method Max Payment Limit Check 30d Same Method Max Payment Limit Check 24h Same Credit Card Count Check ... and many options more .... |
| Velocity Checks | Velocity Checks are used to compare certain criteria like: IP address, Issuer Country, User Country, number of cards used... | User Country Risk Check IP Country To User Country Check Credit Cards Per User Check Wallet Accounts Per User Check * ... and many options more .... |
| Referral List Checks | Referral List checks can be used to blacklist or whitelist users, IP addresses, email addresses, ... | Username Black Referral List Check Email Black List Referral Check Credit Card Number White Referral List Check ... and many options more .... |
| Allowed Cards | To check if a card is allowed to be used. | Credit Card Funding Source Type Check Payment Region Check |
| Bonus Checks | Bonus related checks | * First Executed Deposit Period Check |
| Compliance | Complicance related checks | * First Withdrawal Check |
| Payment details verification | Checks to be done based on payment details. | IBAN Validation Check PayPal User Verified Check |
| Others | Other unclassified scoring checks | Card Holder Last Name Check Users Per Payment Account Check * ... and many options more .... |
Scoring Phase 1 and 2
Depending on the use-case, it is possible to have two scoring phases done for one payment:
- Scoring Phase 1: This phase is done after the payment creation/validation and before the payment is authorised.
- Scoring Phase 2: This phase is done after the payment was authorised with the provider/schemes and PXP System has received certain information from the provider that will be used to execute the scoring checks in the Scoring Phase 2.
The below table shows the possible states that a payment can have after the scoring phase was executed:
| Use-case | State | Details | Next steps |
|---|---|---|---|
| Approved | If ScoringPhase1: ApprovedByPaymentScoring (201)If Scoring Phase 2: ApprovedByPaymentScoringPhase2 (274) | The total score of all executed checks are below the configured threshold and the payment was automatically approved. | The payment will continue automatically with the next step int he payment workflow, e.g. 3DS check, authorisation with provider/schemes. |
| Blocked (only applicable for withdrawals) | If ScoringPhase1:BlockedByPaymentScoring (202)If Scoring Phase 2: BlockedByPaymentScoringPhase2 (275) | The total score of all executed checks are above the configured blocking-threshold and the payment was automatically blocked. | An operator needs to login to PXP Admin Tool and approve or refuse the payment manually. This could also be done via API call. |
| Refused | If ScoringPhase1:RefusedByPaymentScoring (121)If Scoring Phase 2: RefusedByPaymentScoringPhase2 (276) | The total score of all executed checks are above the configured refusal-threshold and the payment was automatically refused. | The payment cannot be continued. This is a final state. |
Scoring Phase 2 and Automatic Abortion
The Scoring Phase 2 is executed by the PXP system after the payment was successfully authorised with the schemes (e.g. Visa/MC).
Instead of moving the payment directly from state AuthoriseResponseReceivedFromProvider to the authorised state (AuthorisedByProvider in case of a Card Deposit, WithdrawnByProvider in case of a Withdrawal), the payment will result in the regarding ScoringPhase2 state.
The State Diagram shows an overview about the possible state changes.
Authorisation refused case
If the authorisation was refused or an error happend during authorisation, the payment scoring phase 2 will not be done and the payment remains in
RefusedByProvider(or the regarding error state).
The below table shows the possible states that a payment can have after the scoring phase 2 was executed:
| Scoring State | What happens next? | Info to merchant |
|---|---|---|
ApprovedByPaymentScoringPhase2(274) | The payment will continue to state AuthorisedByProvider automatically. | Merchant System receives response with this state. |
BlockedByPaymentScoringPhase2 (275) | The payment will remain in that state until it is approved or refused by an operator. | Merchant System receives response with this state. |
RefusedByPaymentScoringPhase2 (276) | The payment will be aborted automatically in a next step. | Merchant System receives response with this state. |
Automatic Abortion
In case the payment was refused by the 2nd scoring phase (=RefusedByPaymentScoringPhase2), the PXP system tries to abort the payment with the provider/schemes.
The standard notification mechanism is used for notifying the merchant in the background (asynchronously) about the result of this abortion. For more information see PaymentStateChangedNotification.
Abortion results - possible states in the notification:
| State | Description |
|---|---|
AbortedOnProvider (397) | The payment was successfully aborted (cancelled) on provider side. |
AbortCommunicationErrorOccurred (394) | Communication error |
AbortErrorReportedByProvider (395) | Provider could not abort/cancel the payment. |
AbortRefusedByProvider (396) | Provider refused to abort/cancel the payment. |
Example handlePaymentStateChangedNotificationRequest for Visa Deposit in Aborted state:
State Diagram
Card Fraud Prevention using Fraudsight
PXP Financial is connected to the real-time Card Fraud Prevention Service offered by FisGlobal: Fraudsight.
- FraudSight helps stop in-store and online fraud while increasing approval rates and minimizing false positives.
- FraudSight is a multilayered fraud solution that combines unparalleled data insights, industry leading technology, and payment fraud prevention expertise to most accurately predict if a transaction is fraudulent.
Supported Acquirers
Fraudsight Card Fraud Prevention is currently supported for the following acquirers:
- PXP Acquiring in the US (PXPUS)
- Braintree
- Vantiv
Adding this feature for other acquirers is possible on request.
Post Authorisation scoring - Scoring Phase 2
The Fraudsight scoring checks are executed in PXP Payment Scoring Phase 2 - after the payment was authorised with the Provider, because certain data from the authorisation is needed.
Payment and Customer data to be provided
As part of the Fraudsight-check, some payment and user data need to be sent to the FraudSight-API. The merchant has to collect this data during the payment process and transmit to PXP in order to use the Service.
The following elements should be provided in the initiatePayment or getRedirectData request to increase the effectiveness of the fraudsight scoring:
| Field | Value |
|---|---|
| user.address.street user.address.houseNumber user.address.postalCode user.address.countryCode2 | The customer/user address |
| user.email | The email address of the customer/user |
| user.address.telephoneNumber | The phone number of the customer/user |
Fraudsight Scoring check
There is one scoring check available in the PXP System called QueryFraudSightRealTimePostAuthRiskCheck which does the scoring with Fraudsight.
The check does the following:
- Relevant customer and payment related data is sent in real-time to the Fraudsight API
- Fraudsight executes their checks and returns the result to PXP
- the PXP scoring check evaluates the Fraudsight result and moves the payment to the
ApprovedByPaymentScoringPhase2orRefusedByPaymentScoringPhase2state - If
ApprovedByPaymentScoringPhase2payment will be moved toAuthorisedByProviderstate and PXP system responds this state to the merchant system - If
RefusedByPaymentScoringPhase2this is the end state and PXP system responds this state to the merchant system
The below table explains the possible Fraudsight results and how they are interpreted by the PXP Scoring Check:
| Fraudsight Result | Score | Example message in the scoring check |
|---|---|---|
| pass Payment passed the Fraudsight scoring | payment will be moved to ApprovedByPaymentScoringPhase2(274) if no other checks score high enough (sum of all scoring checks executed in Phase 2 must be below the configured threshold, which is normally 1000) | RiskStatus=pass; OverallScore=0,011700000; OutputTags=[ "pass", "0.057717068416597794" ]; TriggeredRules=[ "Between1001and50_riskOutput_pass" ] |
| fail Payment failed the Fraudsight scoring | payment will be moved to RefusedByPaymentScoringPhase2 (276) | RiskStatus=fail; OverallScore=0,013500000; OutputTags=[ "fail", "0.05019383540864092" ]; TriggeredRules=[ "LessThan10_riskOutput_fail" ] |
| review Payment did not pass the Fraudsight scoring, review suggested | payment will be moved to RefusedByPaymentScoringPhase2 (276) | review RiskStatus=review; OverallScore=0,294500000; OutputTags=[ "review", "0.05302798214318338" ]; TriggeredRules=[ "Between5001and100_riskOutput_review" ] |
| error Fraudsight scoring could not be done due to an error | payment will be moved to RefusedByPaymentScoringPhase2 (276) | Message=Unhandled exception occurred while calling the ExternalRealTimeCheck for Payment[ID=38101565]! The check score will be selected as if the check was unsuccessful ("potential match"). |
Automatic Abortion if RefusedByPaymentScoringPhase2
In case the payment was refused by the Fraudsight scoring (state is RefusedByPaymentScoringPhase2), automatic abortion is done and the merchant will receive a handlePaymentStateChangedNotificationRequest with the result of the abortion.
Fraudsight Fraud Model Learning
The Fraudsight Card Fraud Prevention Service is able to learn, when it is fed with additional chargeback related information. This will improve the fraud prevention logic and will assure the quality of future scorings.
Merchants that want to use the Fraudsight Card Fraud Prevention tool have to allow and enable PXP Financial to retrieve their chargeback information directly from the acquirer. The PXP system can then automatically forward the relevant information for each first chargeback created to Fraudsight.
Allow PXP to use Chargeback information
To allow and enable PXP Financial to retrieve and use the merchants Chargeback data for feeding the Fraudsight Fraud Model Learning Tool, please contact the PXP Support Team or your PXP Account Manager.
Updated about 3 years ago