Testing Your Integration

As with all software, it’s important to get it working, and then keep it working. Ravelin has multiple features to aid you in testing your integration. To ensure safe usage, the below features are only enabled for sandbox accounts.

Forcing a specific action

You should ensure that you are listening to the action that Ravelin returns, and handling it appropriately. By default, a Payment Fraud action can be forced by using a customer email with the following email domains:

  • @qa-force-allow.com → ALLOW
  • @qa-force-review.com → REVIEW
  • @qa-force-prevent.com → PREVENT

If you are integrating or testing any changes with the Account Takeover API, use a username with the following email domains to force an action for a v3/login reponse:

  • @qa-force-ato-permit.com → PERMIT
  • @qa-force-ato-warn.com → WARN
  • @qa-force-ato-block.com → BLOCK

As part of the Account Takeover product we maintain a breached credentials database. If you want to test a credentials check status use one of the following examples:

  • use a common bad password like “password1” or “password” → for a passwordBreached = true
  • use this email as the username “test@example.com” → for a usernameBreached = true

NOTE: These examples for breached credentials are also available in live accounts, not just in sandbox ones.

Simulating slow networks

Networks are inherently unreliable. Your system should be robust against slow responses from the network, and from Ravelin.

Sending the Ravelin-Min-Latency header, with the specified delay in milliseconds will ensure that all requests you make will take at least the specified duration in milliseconds on Ravelin’s servers. This can be used to test your system’s behaviour when an abnormal increase in network latency, or Ravelin’s latency occurs.