OroPocket
Hosted embed

Test a hosted embed in the Playground

The Playground has an Embed tab that issues a real user_code and loads the actual hosted checkout in a phone frame inside the dashboard. You can drive the entire buy flow before you write a line of app code.

5 min read · 3 screenshots

The hosted embed is the lowest-code path: you issue a code for a user, load a URL in a WebView, and OroPocket renders buying, selling and KYC. This page is about proving that works before you build the WebView.

The Embed tab only appears if your keys carry the embed capability. If you cannot see it, tick Hosted integration on the Capabilities page and save.

  1. Open the Playground and switch to the Embed tab

    Playground is in the Build section. The tabs across the top are filtered to what your keys can call; pick Embed (hosted).

    The OroPocket Playground with the Embed (hosted) tab selected, showing an Issue a user_code form on the left and an empty phone preview on the right.
    Tester on the left, live request log on the right, phone preview below.

  2. Issue a user_code

    Enter a mobile number — or press Random new number for a fresh one — and press Issue and load. That calls the same endpoint your server would:

    POST/partner/users/initembed
    The Issue a user_code card in the OroPocket Playground Embed tab, with fields for mobile, name, email and an embed origin override, plus Issue and load, Random new number and Reuse buttons.
    Reuse 9876543210 exercises the returning-user path; a random number exercises first-time onboarding.
    The response contains two different codes and confusing them is the most common embed bug. data.user_code is the stable identity you store and that every webhook echoes back. The code inside embed_url is a separate single-use handoff token that expires in ten minutes. Never build the URL yourself from the stable code.

  3. Drive the flow in the phone preview

    The preview loads the real hosted checkout at connect.oropocket.com in a 390-pixel frame. It is not a mock — it is the same page your users will see.

    The phone preview in the OroPocket Playground showing the hosted embed's Verify your mobile screen, with a masked mobile number, a four-digit code field and a Verify button.
    In Test mode the channel reads SANDBOX and the OTP is always 1234 — no SMS is sent and none is billed.

    Enter 1234 and you are through to the buy screen. From there the flow is the user’s: pick an asset, enter an amount, pay.

  4. Read the request log

    Every call the tester makes appears in the Live log on the right, request and response, newest first. Each entry has a copy curl link that produces the exact command with your key in it — which is usually the fastest way to move from clicking to code.

Testing against a local build

The Embed origin (dev override) field swaps the host in the returned URL while keeping the ?u= query intact, so you can point the preview at a local build of the embed and still get a genuine server-issued code. It is remembered between visits.

What Test mode will not let you do

BehaviourIn Test mode
OTPAlways 1234. No SMS is sent, so nothing is billed.
Transactions inside the embedBlocked outright with 403 SANDBOX_MODE_NO_TRANSACTIONS. Sandbox embed sessions can sign in and browse, but cannot buy — test buys go through the API tabs instead.
AttributionSandbox users are deliberately left unattributed, so test traffic never affects real commission.
PricesReal and live. Only settlement is simulated.
When you move to a real WebView there is host configuration you must get right — multi-window support, UPI deep links and file uploads for KYC. That is all in the WebView & UPI setup guide. For the endpoints themselves, see the hosted embed reference.
← Choose your capabilitiesSee users and transactions →