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

# Terms and Conditions

> How to manage Terms and Conditions acceptance for customers when integrating via the Ramps API.

## Overview

The Partner integrating with Ripio via API shall be responsible for ensuring that their customers explicitly accept Ripio's Terms and Conditions (T\&C) prior to performing any on-ramp or off-ramp operations.

## Acceptance is per version, not per customer

Terms and Conditions are versioned per country, and **only one version is active at a time**. Activating a new version deactivates the previous one, and an acceptance is always recorded against the specific version that was shown.

That has one consequence worth designing for: **a customer who accepted an earlier version counts as not having accepted.** A customer who accepted version `1.0` for Mexico is blocked again the moment version `2.0` becomes active for Mexico, and stays blocked until they accept the new one — no matter how long they have been operating or whether their KYC is approved.

<Warning>
  Acceptance is not a one-off onboarding step. Treat it as a gate you re-check, not a flag you store:

  * **Do not cache `accepted: true`.** It answers for the version that was active when you asked.
  * **Do not cache the `termsId`.** Once the version it belongs to is replaced, sending it to [Accept Terms](/ramps-api/customers/accept-terms) fails with `20040`.
  * Re-check before operating, or handle `20039` wherever you create something, and send the customer back through the acceptance flow.
</Warning>

## How it works

When T\&C acceptance is required for your account, any attempt to operate without an acceptance of the **currently active** version returns `20039`:

```json theme={null}
{
  "code": 20039,
  "type": "TermsAndConditionsNotAcceptedException",
  "detail": {
    "message": "Customer '3fa85f64-5717-4562-b3fc-2c963f66afa6' has not accepted the current Terms and Conditions."
  },
  "status": 400
}
```

The `message` carries the `customerId` you sent in the request — no email or external reference.

The check is not limited to creating a session. Every one of these endpoints answers `20039` when the active version has not been accepted:

| Endpoint | Page |
| - | - |
| `POST /api/v1/customers/{customerId}/kyc/` | [Submit KYC Information](/ramps-api/kyc/submit-kyc-information) |
| `POST /api/v1/customers/{customerId}/fiatAccount/` | [Create Deposit Account](/ramps-api/customers/create-deposit-account) |
| `POST /api/v1/fiatAccounts/` | [Create Fiat Account](/ramps-api/fiat-accounts/create-fiat-account) |
| `POST /api/v1/onramp/` · `POST /api/v1/onrampSession/` | [Create On-Ramp Order](/ramps-api/on-ramp/create-on-ramp-order) · [Create On-Ramp Session](/ramps-api/on-ramp/create-on-ramp-session) |
| `POST /api/v1/offramp/` · `POST /api/v1/offrampSession/` | [Create Off-Ramp Order](/ramps-api/off-ramp/create-off-ramp-order) · [Create Off-Ramp Session](/ramps-api/off-ramp/create-off-ramp-session) |

Note that KYC submission is included: a returning customer whose KYC you resubmit after a new version went live is refused there too, before any order is involved.

## Checking acceptance status

Before showing the T\&C screen to a customer, check whether they have already accepted the currently active Terms and Conditions. This avoids presenting the acceptance screen unnecessarily to returning customers.

```http theme={null}
GET /api/v1/customers/{customerId}/termsAcceptance/
```

**Response example — customer has already accepted:**

```json theme={null}
{
  "termsId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "country": "AR",
  "version": "1.0",
  "url": "https://example.com/terms/v1.0",
  "accepted": true,
  "acceptedAt": "2024-06-01T12:00:00Z"
}
```

**Response example — customer has not yet accepted:**

```json theme={null}
{
  "termsId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "country": "AR",
  "version": "1.0",
  "url": "https://example.com/terms/v1.0",
  "accepted": false,
  "acceptedAt": null
}
```

Every field describes the **active** version: `termsId`, `version` and `url` are the ones in force right now, and `accepted` answers for that version alone. A customer who accepted an earlier version reads as `accepted: false`, with `acceptedAt: null` — the timestamp belongs to the acceptance of the active version, so there is no record of the older one in this response.

When `accepted` is `true`, proceed directly with on-ramp or off-ramp operations. When `accepted` is `false`, display the T\&C document (via `url`) and record the customer's acceptance before continuing.

<Note>
  When no active Terms and Conditions exist for the account's country, `accepted` is always `true` and
  the term fields (`termsId`, `version`, `url`) are `null`. The customer is not blocked and no
  acceptance is required.
</Note>

## Acceptance Flow

### 1. Get the active Terms and Conditions

Retrieve the current active T\&C for your account's country. This returns a `termsId` that you'll need in the next step.

```http theme={null}
GET /api/v1/termsAndConditions/
```

**Response example:**

```json theme={null}
{
  "termsId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "country": "AR",
  "version": "1.0",
  "url": "https://example.com/terms/v1.0"
}
```

Show the T\&C document (via `url`) to the customer and collect their acceptance.

### 2. Record the customer's acceptance

Once the customer has accepted, send the acceptance record to the API including the `termsId`, the customer's IP address, and optionally their user agent.

```http theme={null}
POST /api/v1/customers/{customerId}/acceptTerms/
```

**Request body:**

```json theme={null}
{
  "termsId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "ipAddress": "192.168.1.100",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
```

**Response example (`201 Created`):**

```json theme={null}
{
  "termsId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "ipAddress": "192.168.1.100",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
  "acceptedAt": "2024-06-01T12:00:00Z"
}
```

Only the active version can be accepted. A `termsId` that belongs to a version already replaced is refused with `20040` `TermsAndConditionsNotFoundException` and `404`, which is what a stored `termsId` turns into once a new version goes live — read it as "fetch the active terms again and show them", not as "the customer does not exist".

After a successful acceptance, the customer can proceed with on-ramp and off-ramp operations normally, until a new version becomes active for the country.

## Where this shows up in the widget

Partners on the [Ramps widget](/ramps-api/widget/overview) do not implement any of this: the widget presents the active terms and records the acceptance itself, against the same platform state. A new version sends returning widget users back through the sign-in step so they can accept it — see [Sign-in and terms](/ramps-api/widget/flows/identity-and-terms).


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