Payment Flow

The sequence in which a fraud solution is integrated into a payment flow is crucial to maximising its effectiveness. If the sequence is not correct then many data sets, and therefore many features, will not be collected and exposed to the solution.

Auth then Capture

The optimal payment flow, when using auth then capture, has been detailed in the following sequence diagram.

sequenceDiagram participant Browser participant Your Server participant Ravelin participant Payment Gateway opt RavelinJS Browser->>Ravelin: Behaviour and Device Info end loop While payment is not successful Browser->>Your Server: Attempt Payment Your Server->>Payment Gateway: Attempt Authorisation Payment Gateway-->>Your Server: Authorisation opt Authorisation = Granted Your Server->>Ravelin: /v2/checkout?score=true Ravelin-->>Your Server: Action opt Action = Allow Your Server->>Payment Gateway: Capture Payment Payment Gateway-->>Your Server: Capture Response end opt Action = Review Your Server->>Payment Gateway: Initiate 3DS Sequence Payment Gateway-->>Your Server: 3DS Response end end Your Server->>Ravelin: /v2/checkout Your Server-->>Browser: Payment Response end

The first data, optional but highly advised, to send is behaviour and device info (screen size, browser type, keys pressed…). This is sent directly from the browser to Ravelin using our RavelinJS Library.

When a payment attempt is made from a browser, the format of the payment method data will depend on your PCI compliance and how you integrate with your Payment Gateway. If you are currently using client side encryption with your Payment Gateway then it is highly recommend using our RavelinJS Library to encrypt the card data.

After an authorisation request to your gateway has completed, a call to /v2/checkout?score=true can be made to Ravelin to review the attempted payment. It is vital that this request includes transaction information returned from the authorisation attempt so that Ravelin can create a more accurate decision and score. If the authorisation has failed Ravelin will still need to be updated.

Finally, if both the the gateway and Ravelin have given the green light, you can capture the payment and update Ravelin. If either the capture or authorisation failed it is necessary to update Ravelin with this information This update is most commonly done with another /v2/checkout call.

Combined Auth-Capture

The optimal payment flow, when using auth and capture, has been detailed in the following sequence diagram.

sequenceDiagram participant Browser participant Your Server participant Ravelin participant Payment Gateway opt RavelinJS Browser->>Ravelin: Behaviour and Device Info end loop While payment is not successful Browser->>Your Server: Attempt Payment Your Server->>Ravelin: /v2/checkout?score=true Ravelin-->>Your Server: Action opt Action = Allow Your Server->>Payment Gateway: Auth and Capture Payment Payment Gateway-->>Your Server: Auth and Capture Response end opt Action = Review Your Server->>Payment Gateway: Initiate 3DS Sequence Payment Gateway-->>Your Server: 3DS Response end Your Server->>Ravelin: /v2/checkout Your Server-->>Browser: Payment Response end

Crucially, when using an auth and capture, the Ravelin decision must occur before any transaction information could be collected. This type of data is critical to making a decision on whether a payment is fraudulent or not. Was the auth successful? Was the AVS correct? Was the CVV correct? It is recommended to use an auth then capture payment sequence when integrating Ravelin into your payment flow due to this difference.

It is very common for fraudsters to have numerous failed attempts when buying online. The failed transactions can only be recognised by Ravelin, and used in future scoring, if an update is sent out to Ravelin. The most common way to do this is using another call to /v2/checkout although calls to /v2/pretransaction and /v2/transaction can be used before and after a transaction attempt respectively.

Additionally, this payment sequence can continue in a loop as the customer repeatedly attempts to transact. All instances of these attempts must be sent to Ravelin so we can block all subsequent attempts and track fraudulent signals between attempts (such as switching card or changing a billing address to try and pass an AVS check). Do not prevent any users, no matter how highly Ravelin scores them, from attempting transactions; the information we gather from subsequent attempts is useful to help prevent future attacks. Instead, simply display a generic error and allow the user to futilely retry.