Payment Fraud Integration

Requesting recommendations

On this page:

Requesting a recommendation

This is our recommended payment flow integration.

The diagram below shows the payment flow for requesting a recommendation before authorisation. This integration allows us to help you decide which transactions to send to 3D Secure, as well as avoid the cost of authorisation transactions that we recommend preventing.

In order to score before authentication and authorisation, the pspBeforeAuth checkpoint should be called (by adding a parameter of ?checkpoint=pspBeforeAuth) as you send your transaction data to the transaction endpoint.

PSP payment fraud integration guide pre-authorisation flow

%%{ init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#ececff' 'fontFamily': "Helvetica", "sans-serif" } } }%% sequenceDiagram autonumber participant PAYMENT_PAGE as Payment page participant PSP_BACKEND as PSP backend participant RAVELIN as Ravelin participant CARD_SCHEMES as Card schemes PAYMENT_PAGE ->> PSP_BACKEND: Attempt payment PSP_BACKEND ->> RAVELIN: Request recommendation RAVELIN ->> PSP_BACKEND: Recommendation opt If Allow recommendation PSP_BACKEND ->> CARD_SCHEMES: Attempt authorisation and capture CARD_SCHEMES ->> PSP_BACKEND: Authorisation and capture response end opt If Review recommendation PSP_BACKEND ->> CARD_SCHEMES: Attempt authentication CARD_SCHEMES ->> PSP_BACKEND: Authentication response opt If Authentication was successful PSP_BACKEND ->> CARD_SCHEMES: Attempt authorisation and capture CARD_SCHEMES ->> PSP_BACKEND: Authorisation and capture response end end opt If Prevent recommendation PSP_BACKEND ->> PSP_BACKEND: Stop processing end PSP_BACKEND ->> PAYMENT_PAGE: Payment response

Requesting a recommendation after authorisation

Only use this flow if you authorise and capture separately. It is not recommended for markets where authentication regulations must be met.

The diagram below shows the payment flow for requesting a recommendation after authentication and authorisation, but before you capture the payment.

In order to score after authentication and authorisation, the pspAfterAuth checkpoint must be used.

PSP payment fraud integration guide post-authorisation flow

%%{ init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#ececff' } } }%% sequenceDiagram autonumber participant PAYMENT_PAGE as Payment page participant PSP_BACKEND as PSP backend participant RAVELIN as Ravelin participant CARD_SCHEMES as Card schemes PAYMENT_PAGE ->> PSP_BACKEND: Attempt payment PSP_BACKEND ->> CARD_SCHEMES: Attempt authorisation CARD_SCHEMES ->> PSP_BACKEND: Authorisation response opt If Authorisation is successul PSP_BACKEND ->> RAVELIN: Request recommendation RAVELIN ->> PSP_BACKEND: Recommendation response opt If Allow recommendation PSP_BACKEND ->> CARD_SCHEMES: Attempt capture CARD_SCHEMES ->> PSP_BACKEND: Capture response end opt If Prevent recommendation PSP_BACKEND ->> PSP_BACKEND: Stop processing end PSP_BACKEND ->> PAYMENT_PAGE: Payment response end

Transaction updates

It is important that you update us on the outcome of all authentication and authorisation attempts, as well as any other updates to the transaction lifecycle. This includes capture and refund events. The transaction.type field can be used to help specify which transaction lifecycle event the update is for.

Obtaining previous scores

If you need to request scoring data for a previously scored transaction, you can do so by calling our score endpoint. You will need to send the transaction ID used for the original scoring request, as well as the score ID returned in the score response.

Feedback