Skip to main content

​
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.
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 fails with 20040.
  • Re-check before operating, or handle 20039 wherever you create something, and send the customer back through the acceptance flow.

​
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:
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: 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.
Response example — customer has already accepted:
Response example — customer has not yet accepted:
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.
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.

​
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.
Response example:
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.
Request body:
Response example (201 Created):
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 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.