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

# Sign-in and terms

> The email and one-time-code step every widget user goes through, and where Terms & Conditions acceptance is recorded.

Before a user can buy or sell, the widget establishes who they are by email. **This is the first thing they see** — both the on-ramp and the off-ramp open on it — and it happens entirely on Ripio's side, with nothing for you to build or configure.

### What the user sees

<Steps>
  <Step title="Enter an email address">
    The widget opens asking for the email where the user wants to receive updates about their operations. Ripio collects it — it is not the `external_ref` you used to mint the session token, and you are not asked to supply it.

    <img src="https://mintcdn.com/ripio-9dfd4837/08vkB56X36FZiua_/ramps-api/widget/assets/widget-sign-in-email.png?fit=max&auto=format&n=08vkB56X36FZiua_&q=85&s=4a3cbe3816bb3886259aec4783c01253" alt="The first screen of the widget, asking for an email address" width="634" height="1046" data-path="ramps-api/widget/assets/widget-sign-in-email.png" />
  </Step>

  <Step title="Enter the code we email them, and accept the terms">
    A 6-digit code arrives by email. The user can ask for a new one after 60 seconds, and repeated requests are rate-limited to protect their inbox. The Terms & Conditions are presented on this same screen, so acceptance and verification happen together.

    <img src="https://mintcdn.com/ripio-9dfd4837/08vkB56X36FZiua_/ramps-api/widget/assets/widget-sign-in-code.png?fit=max&auto=format&n=08vkB56X36FZiua_&q=85&s=1a4cc9e05084a1c2020dd68c4a301900" alt="The code entry screen with the Terms & Conditions checkbox" width="854" height="1140" data-path="ramps-api/widget/assets/widget-sign-in-code.png" />
  </Step>
</Steps>

<Note>
  A wrong code is not treated as an error: the widget simply tells the user it did not match and lets them try again. There is no lockout to design around.
</Note>

### How the terms appear

Three cases, depending on what is active for your account's country:

| Situation                                       | What the user sees                                                                                                     |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| There are active terms they have not accepted   | A checkbox they must tick — "I have read and accept the Terms & Conditions" — before the confirm button becomes usable |
| Terms apply but no specific version is in force | A single line stating that continuing implies acceptance, with a link to the document                                  |
| The country has no active terms                 | Nothing; the section is not rendered at all                                                                            |

### Terms & Conditions are shared with your API integration

The active terms and the record of who accepted them live in the Ramps platform, not in the widget. That has one useful consequence: **an acceptance you registered through the API counts here too.** A customer who already accepted the current terms via [Accept Terms](/ramps-api/customers/accept-terms) is not asked again inside the widget.

The reverse also holds. When a user accepts the terms inside the widget, [Get Terms Acceptance Status](/ramps-api/terms-and-conditions/get-terms-acceptance-status) reports it for that customer, so your backend can read the acceptance without the user having to repeat it.

<Note>
  When there are no active terms for the country, this step is skipped entirely and the acceptance status reads as accepted. See [Terms and Conditions](/ramps-api/terms-and-conditions/introduction) for the full model.
</Note>

### What your backend does

Nothing. There is no event for sign-in, and no call for you to make. The first thing your backend hears about a widget user is the operation they start afterwards, through the [Ramps webhooks](/ramps-api/webhooks/introduction) keyed by the `external_ref` you minted the token with.