Skip to main content
The embedded iframe reports what happens inside it through postMessage messages to the window that contains it:
The SDK does nothing magic with that: it listens to those same messages and re-emits them under friendlier names. This page documents the layer underneath, for when you mount the iframe by hand.
If you can use the SDK, use it: it saves you the listener, the origin validation and the iframe height. This page is for when you cannot install a package, or you already have your own iframe in place.

Mounting the view by hand

The widget has two views and each one emits its own set of messages. They are the same ones the SDK mounts, and the URL tells them apart: the autopay one ends in /autopay.
You can identify your company with companyCode instead of the alias:
This is different from embedding the full portal, which shows the debt list. Here you mount only the widget.

Listening to the messages

Always validate event.origin. The messages are emitted with targetOrigin: "*", so your listener also receives whatever any other iframe or script on your page sends. Without that check, anyone can fake a TapiPay event from the user’s browser.
In the sandbox environment the origin is https://homo.tapipay.la.
The shape of the data is not the same as in the SDK. The raw message is { type, payload }: the content travels inside payload. The SDK hands that payload unwrapped to your handler, but here you have to read event.data.payload.

Lifecycle signals

Both views emit these three signals while they run inside an iframe, no matter what your user does.
TAPIPAY_RESIZE is the exception to the payload rule: the height travels at the root of the message, in event.data.height.
None of them has a matching SDK event, because the SDK handles them internally: it uses TAPIPAY_JS_READY to remove its loading screen and TAPIPAY_RESIZE to adjust the iframe height. If you mount the iframe by hand, that is on you.

The messages

Every message has its matching SDK event. The payload is identical in both cases, with the same field names.

Enrollment flow

One message per step your user completes during enrollment. The first four arrive once each, in order.
TAPIPAY_DOMICILIATION_CONFIRMED means your user pressed confirm, not that the enrollment became active. The backend processes it asynchronously. The real confirmation is TAPIPAY_AUTOPAY_ACTIVATED.

Enrollment management

Card payment

These come from the payment methods view, when your user pays by card inside the widget. TAPIPAY_PAYMENT_WINDOW_OPENED and TAPIPAY_PAYMENT_CANCELLED arrive with no data: they tell you the payment window opened and that your user closed it without finishing.
TAPIPAY_PAYMENT_SUBMITTED means submitted, not settled. Never mark a debt as paid from this message: the real status arrives through the payment notification to your backend.

Autopay payloads

The fields of the enrollment and autopay management messages, with their types.

Payment payloads

The fields of the card payment messages, with their types.