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 ApprovedByPaymentScoringPhase2 or RefusedByPaymentScoringPhase2 state
  • If ApprovedByPaymentScoringPhase2 payment will be moved to AuthorisedByProvider state and PXP system responds this state to the merchant system
  • If RefusedByPaymentScoringPhase2 this 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.