Skip to main content
Migo Docs

Hosted Webview

Migo's hosted webview is a self-contained checkout UI served at the URL returned when you create a transaction (see Create a Payment Link). The merchant only needs to deliver that URL to the customer — the webview drives the entire payment flow on Migo's side.

The integrator only creates the transaction

By API you make a single call: creating the transaction/payment link. Everything described below — loading the checkout, capturing card data, installment selection, 3D Secure, charging, and the final redirect — happens inside Migo's hosted webview. You never collect card data, never tokenize, and never call a charge endpoint yourself.

What the customer experiences​

deliver URL ──► customer opens hosted webview ──► pays ──► merchant redirect
                  │                                  │
                  │  1. webview loads config         │  enters card · picks
                  │     and payment methods          │  installments · 3D Secure
                  │     for your account             │  · confirms
                  └──────────────────────────────────┘

1. The webview loads your checkout​

When the customer opens the URL, the webview resolves your merchant account configuration and renders the checkout automatically. It applies:

  • Return URLs — where the customer is sent back to your site after the payment, with the result encoded in query parameters (uid, status, reference).
  • Enabled payment methods — the payment methods (card processors and rails) enabled for your merchant account, used to render the method picker.
  • Branding — your logo and primary color for visual personalization.

Migo personalizes the return URLs so they already carry transaction identifiers like the transaction uid, its status, and the human-friendly reference.

2. Per-method configuration​

For each enabled payment method the webview renders the method-specific UI, including:

  • Accepted card brands and BIN ranges
  • Installment options
  • Any required additional fields (for example a document type / id for certain rails)

3. Optional extra fields​

If your merchant account requires extra fields (shipping address, document number), the webview captures them and attaches them to the transaction's additionalData, where they become available to the payment method and to the outbound merchant notification.

4. Card entry, installments, and charge​

Inside the webview the customer enters their card details, picks the number of installments (when the method supports them), and confirms. Migo then tokenizes the card and charges the transaction against the payment method selected for your merchant account — all internally. The customer-facing flow is identical regardless of which payment method ends up being used.

5. 3D Secure​

If the payment method requires 3D Secure, the webview presents the challenge to the customer, collects the response, and completes authentication before the charge is finalized — no integrator action is involved.

6. Closing the webview​

After a successful charge — or when the customer dismisses the checkout — Migo redirects the browser back to your return URL with the result encoded in query parameters. Your site reads those parameters to update the customer-facing state.

Receiving the authoritative result​

The browser redirect is for the customer's experience; it is not your source of truth. The authoritative outcome is delivered to your backend once the transaction reaches a terminal status, via the Merchant Generic Callback. Reconcile against that callback, correlating with the transaction uid you received when you created the link.