postMessage messages to the window that contains it:
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.
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
https://homo.tapipay.la.
Lifecycle signals
Both views emit these three signals while they run inside an iframe, no matter what your user does.
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. Thepayload 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.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.
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.

