Skip to main content
The IngoPay Risk API assesses transaction risk before a pull (debit) payment. Ingo partners with Sardine for device fingerprinting and behavioral analytics. The risk score therefore depends on signals your web and mobile apps collect, as well as the data you send to the API. A Risk integration has three workstreams. Only the first is covered by the API reference in this section.
Sardine’s implementation guides are not public. Your Ingo Integration Manager provides them, along with the SDK packages, once your Ingo agreement is in place. Your Ingo agreement covers the terms for their use.

​
How the pieces fit together

1

Start a risk session

Your backend calls Risk Session and receives a risk_session_token.
2

Collect device and behavior signals

Your web or mobile app starts the Sardine SDK with the risk_session_token. The SDK collects device and behavior signals while the customer uses your app. Web apps send this data through the subdomains you configured in DNS.
3

Request a risk score

Your backend calls Risk Score with the transaction details and the same risk_session_token. The response contains a score and a risk_assessment_token.
4

Submit the payment

Include the risk_assessment_token in the debit process request.

​
Fraud guarantee

With the fraud guarantee, Ingo covers the transaction amount and chargeback fees if a guaranteed transaction is later found to be fraud. Your integration is set to one of three guarantee modes during onboarding. You don’t choose the mode per request.
In First transaction mode, the first transaction is counted per funding account, not per customer. A returning customer who adds a new card or bank account gets a guarantee request on that new account. A declined or failed debit doesn’t count as the first transaction. Ingo keeps requesting a guarantee on that account until a debit completes.

​
Reading the guarantee result

Check response.status first. Use the transaction fields only when the status is 100. Pass the risk_assessment_token into the debit process request before the risk assessment expires. Expiry is set per client. Your Integration Manager can confirm your value.

​
Plan for lead time

The Sardine SDK and DNS work often go through different teams and approval cycles than your backend API work. Start these early. Do not wait until testing begins.

DNS setup (web)

DNS changes often need security or infrastructure review. Ask your Integration Manager for the subdomain values at kickoff so your team can start the change request.

Mobile app releases

Adding the SDK to iOS or Android apps needs an app release. Plan it into your release schedule, and keep the SDK current after go-live.

​
Integration checklist

  1. Ingo agreement in place.
  2. Sardine implementation guides and SDK packages received from your Integration Manager.
  3. Risk Session and Risk Score calls built and tested in sandbox.
  4. Sardine SDK added to each web and mobile app that starts a payment.
  5. Guarantee mode confirmed with your Integration Manager, and your decision logic handles each guarantee result.
  6. Web only: two subdomains created and pointed to the Sardine values you were given.
  7. risk_assessment_token passed into the debit process request.
For implementation guides, SDK packages, or DNS values, contact your Ingo Integration Manager.