> ## Documentation Index
> Fetch the complete documentation index at: https://developers.ingopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Risk Integration Overview

> What a Risk integration involves beyond the Risk API: the Sardine SDK on your web and mobile apps, and DNS setup for web.

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.

| Workstream | Who on your team | What you do | Where the guidance comes from |
| - | - | - | - |
| **Ingo Risk API** | Backend engineering | Call Risk Session, then Risk Score, then pass the `risk_assessment_token` into the debit request | This Developer Center |
| **Sardine SDK** | Web and mobile engineering | Embed the Sardine SDK in your apps and start it with the `risk_session_token` | Sardine implementation guides and SDK packages, provided by your Ingo Integration Manager |
| **DNS setup** (web only) | IT / infrastructure | Create two subdomains on your domain that point to Sardine-hosted endpoints | Values provided by your Ingo Integration Manager during onboarding |

<Info>
  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.
</Info>

## How the pieces fit together

<Steps>
  <Step title="Start a risk session">
    Your backend calls [Risk Session](/docs/ingopay/risk/risk-session) and receives a `risk_session_token`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Request a risk score">
    Your backend calls [Risk Score](/docs/ingopay/risk/risk-score) with the transaction details and the same `risk_session_token`. The response contains a score and a `risk_assessment_token`.
  </Step>

  <Step title="Submit the payment">
    Include the `risk_assessment_token` in the debit process request.
  </Step>
</Steps>

## 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.

| Mode | When Ingo requests a guarantee |
| - | - |
| **Risk score only** | Never. You get a risk score but no guarantee. |
| **All transactions** | On every Risk Score request. |
| **First transaction** | Only when the funding account (the card or bank account behind the `customer_account_token`) has no earlier completed debit. |

<Note>
  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.
</Note>

### Reading the guarantee result

Check `response.status` first. Use the `transaction` fields only when the status is `100`.

| `guarantee_requested` | `transaction_guaranteed` | Meaning |
| - | - | - |
| `"0"` | *(not returned)* | No guarantee was requested for this transaction. Use the risk score to make your decision. |
| `"1"` | `"1"` | The transaction is guaranteed. |
| `"1"` | `"0"` | A guarantee was requested but declined. The transaction isn't guaranteed. Use the risk score to decide whether to proceed. |

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.

<CardGroup cols={2}>
  <Card title="DNS setup (web)" icon="globe">
    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.
  </Card>

  <Card title="Mobile app releases" icon="mobile">
    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.
  </Card>
</CardGroup>

## 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.

<Note>
  For implementation guides, SDK packages, or DNS values, contact your Ingo Integration Manager.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.