Skip to main content
The widget runs inside your page but talks to Ripio’s servers directly, and Ripio’s servers call yours. Each of those paths crosses a boundary your infrastructure controls — a browser policy, a firewall, a TLS check — and a closed one usually fails silently: a blank widget, missing logos, or a buy that never gets approved. This page lists everything to open, per path. See How it works for the paths themselves.

​
Checklist

​
Hosts

Every rule below is per environment: sandbox hosts don’t serve production, and vice versa.

​
Allowed origins

In an embedded integration, the widget’s requests to its API leave from your page’s origin, so the widget API only answers origins registered for it. Send your Ripio contact every origin — scheme, host and port — where you embed the widget, for each environment:
  • An origin is exact: https://yourbank.com and https://www.yourbank.com are two origins, and so are the same host on two ports.
  • A page served from an unregistered origin fails at the very first request: the browser blocks the response, and the widget shows its error screen. The browser console reports it as a CORS error.
  • A WebView integration loads the widget’s own hosted page, whose origin is already registered, so there’s nothing to add for it.

​
Content Security Policy

When you embed the widget, your page’s CSP applies to it. Allow: For sandbox, merged into an existing policy:
  • A blocked logo isn’t an error. If statics.ripio.com is missing from img-src, the widget falls back to an avatar with the token’s initials. Everything still works, but it doesn’t look the way it should.
  • Using nonces or 'strict-dynamic'? With 'strict-dynamic', browsers ignore host allowlists in script-src, so put your nonce on the widget’s <script> tag as you do with your own.
  • style-src 'unsafe-inline' doesn’t open your page to the account theme. The theme isn’t CSS: it’s a list of token values that Ripio validates when it’s stored and the widget validates again before applying it. See Theming.
  • WebView: the hosted page ships its own CSP. There’s nothing to configure.

​
Subresource Integrity

There’s no floating bundle.js: each release publishes a versioned file and its SHA-384 hash, which your Ripio contact sends you. Pin both:
  • crossorigin="anonymous" is required. Without it, the browser can’t check integrity on a cross-origin script and refuses to run it.
  • Load the file straight from Ripio’s host. Don’t re-host it, proxy it, or let a CDN optimizer on your side minify, bundle or defer it: any byte that changes breaks the hash, and a re-hosted copy loads its fonts from the wrong place.
  • Updating is a deliberate step. A new release means a new file name and a new hash. Until you change your snippet, your users keep the version you pinned.
  • The bundle is the only script the widget runs, so its hash covers all of the widget’s code. Its fonts aren’t covered: browsers don’t support integrity on fonts.

​
Your servers

Calling the widget API. Your backend calls POST /auth every time the widget opens:
  • Allow outbound HTTPS from your backend to the widget API’s host.
  • Keep client_id and client_secret in a secrets manager, never in your app or page.
  • The endpoint is rate-limited per account. If you request codes in bulk, expect a 429.
Receiving webhooks. Ripio calls the URL configured on your account for the webhooks. The endpoint must: If your firewall only accepts inbound traffic from known addresses, ask your Ripio contact before going live.

​
WebView

If you point a WebView at the widget’s hosted page:
  • Enable JavaScript. The widget is a web component and doesn’t render without it. It doesn’t use cookies or the browser’s storage, so nothing else needs enabling.
  • Register the native bridge if you want to renew sessions without reloading. See Native Android and iOS.
  • Don’t log WebView URLs. The session code travels in the URL fragment, and your app sees it in navigation callbacks before the widget removes it.