Pay without leaving the page.
A drop-in JavaScript snippet that renders the QR or a deep-link button directly on your checkout — three lines of code, no card form, no redirect, no PCI.
Three lines on your page, no card form anywhere.
The merchant's server creates the payment with the amount fixed server-side. The browser only ever holds an opaque paymentId — a capability token, not a price.
<script src="https://js.miapos.eu/v1/"></script> <div id="mia-pay"></div> <script> miaPOS.mount('#mia-pay', { paymentId, // created server-side; amount is fixed there onSuccess: () => location = '/thank-you', onFail: (e) => console.warn(e.reason), locale: 'ro' | 'ru' | 'en', }); </script>
The widget runs in its own Shadow DOM, polls the payment status, and fires onSuccess the moment the bank confirms. The merchant's backend receives an RSA-signed webhook in parallel — that's the source of truth for the order. Closing the buyer's tab never loses the payment.
How it works.
From cart to confirmation, on the merchant's own page.
/pay with the secret key and an Idempotency-Key. The amount is fixed here, on the merchant's backend. The response is a paymentId.miaPOS.mount('#el', { paymentId, ... }). The widget reads the public, capability-scoped checkout endpoint and renders the QR (desktop) or a "Pay in bank app" button (mobile).onSuccess fires in parallel, but is only used to redirect the buyer's tab.One snippet, every channel with a webview.
The snippet is channel-agnostic by design — no hard redirects, no cookies, no window.location coupling. The same module runs everywhere a webview does.
| Channel | Webview | Snippet runs | Notes |
|---|---|---|---|
| Merchant website | Browser | Yes — as is | Primary use case. |
| Telegram | Mini App | Yes — same code | The widget runs inside the Mini App webview. |
| Instagram & TikTok | Link-out | Yes — on the landing | From bio / Live / Shop link to a miaPOS landing that runs the same snippet. |
| None | Not in-chat | Meta does not allow an in-chat webview. The backend is reused unchanged via a CTA link to a hosted checkout page. |
What it is — and what it isn't.
Embed checkout is one of two e-commerce modes. They are complementary, not competing.
It is
- A JavaScript snippet the merchant embeds on their checkout
- An additive extension of the existing e-commerce protocol — the redirect plugins keep working unchanged
- A channel-agnostic core the same code can run in a Telegram Mini App
- IP-rail only — no card data, no PAN, no 3DS, no PCI
- A capability-scoped endpoint — the browser only ever holds
paymentId
It isn't
- A replacement for payment links — those still own the no-code / invoice / QR-on-receipt scenarios
- A card processor — there are no cards involved at any point
- A page on our domain in an iframe — the widget renders its own UI
- The source of truth for the order — that is the webhook on the merchant's backend
- An in-chat experience on WhatsApp — Meta does not allow a webview there
"The fastest checkout is the one that asks for the fewest fields."
For merchants who own their checkout — and their chats.
The embed snippet fits where the brand is the merchant's, not ours.
D2C web shops
Keep the buyer on the brand's page from cart to confirmation. The checkout never goes to a third-party domain.
HoReCa & services
Pre-orders, deposits, and in-bot booking flows in Telegram Mini Apps — same snippet runs there.
Digital goods
Instant settlement, instant unlock. The widget fires onSuccess the moment the bank confirms.
Social commerce
Instagram and TikTok link-out to a landing that runs the same snippet — one acceptance core.
Subscription & SaaS
Recurring payments are rail-dependent, where the underlying IPS supports them.
Marketplaces & platforms
Drop the snippet into a tenant's checkout without forking the integration per tenant.