What ROKI Connect is
It lets a merchant's server accept card payments three ways. In every one, the merchant never receives, transmits or stores the card number: card entry always happens on a ROKI-controlled surface.
| Mode | What it is | Card entry | Frontend needs | Backend needs |
|---|---|---|---|---|
| 1 - Hosted checkout | Redirect the customer to a ROKI page | ROKI page | nothing | sk_* creates the payment |
| 2 - Embedded components | ROKI card fields in an iframe on your own site | ROKI iframe | pk_* |
sk_* confirms with the amount |
| 3A - Tokenized payments | Charge a card the customer already saved | none | nothing | sk_* charges an opaque pm_* |
Mode 3B is not available yet.
Start with mode 1. It is the simplest, needs no frontend work, and every other mode reuses its payment object, its webhooks and its void/refund/receipt endpoints. Reach for mode 2 when the merchant wants the payment step to look like their own site, and mode 3A when you need to charge a returning customer without asking for the card again.
In modes 2 and 3A the customer's browser talks only to your own backend. Your backend is the only
place that holds sk_* and calls ROKI directly. A "pay with saved card" button must call your
server, never a ROKI secret-key endpoint, and sk_* must never appear in browser code.
The practical consequence is that the merchant stays outside the scope of the PCI-DSS obligations that come with handling card data. It is the same model as Stripe Checkout or the payment links of other processors.
Market: Honduras. Usual currency: Honduran lempira (HNL, ISO numeric code 340).