This changelog covers updates to the Payabli embedded components.
invoiceData object for ExpressCheckout UIWe added the invoiceData object to the ExpressCheckout UI configuration.
The invoiceData object allows you to create an invoice for a transaction when using the ExpressCheckout UI component.
The invoiceData supports the one_time and autopay modes of the ExpressCheckout UI component.
See ExpressCheckout UI for more information about the invoiceData object.
mode field for ExpressCheckout UIWe added the mode field to the ExpressCheckout UI configuration.
The mode field determines the behavior of the ExpressCheckout UI component.
This field accepts three values:
one_time - process one-time transactionsautopay - sets up recurring subscriptions with a billing scheduletokenization - tokenizes payment method without charging customerSee ExpressCheckout UI for more information about the use cases supported by the ExpressCheckout UI component.
saveIfSuccess field for ExpressCheckout UIWe added the saveIfSuccess field to the ExpressCheckout UI configuration.
The saveIfSuccess field enables the ExpressCheckout UI component to process a one-time transaction and tokenize the payment method for future use.
When saveIfSuccess is set to true, the ExpressCheckout UI component saves the payment method if the transaction is successful.
This field only works when the mode field is set to one_time.
See ExpressCheckout UI for more information about the saveIfSuccess field.
Payabli’s Embedded Components Playground has been retired as of April 15th, 2026.
The site at playground.payabli.com is no longer available.
Third-party libraries that the Playground relied on have been deprecated. Unmaintained dependencies pose security risks. For this reason, the Playground has been retired and the site has been taken down.
The documentation already includes tools that cover most of what the Playground offered:
These resources are available now. See the Embedded Components overview for more information.
splitFunding config for ExpressCheckout UIWe added a new splitFunding config option for the ExpressCheckout UI component.
The splitFunding field receives an array of objects containing split funding instructions.
See the ExpressCheckout UI configuration reference for more information.
We added a new rdcAmount input field for the RDC (Remote Deposit Capture) payment method in the EmbeddedMethod UI component.
The rdcAmount input field allows you to specify the amount for the RDC transaction.
See the EmbeddedMethod UI configuration reference for more information.
We added the new RDC (Remote Deposit Capture) payment method to the EmbeddedMethod UI component.
You can enable the RDC payment method by adding the rdc object to the EmbeddedMethod UI configuration.
See the EmbeddedMethod UI configuration reference for details on how to configure EmbeddedMethod UI with RDC.
We added an optional includeDetails flag to the ExpressCheckout UI configuration.
When includeDetails is set to true, the response now includes a transactionDetails object which contains:
This config allows you to retrieve transaction information without making a separate API call.
See the Pay In Transaction integration guide for a complete example of the transactionDetails object structure and usage.
<meta charset="UTF-8"> must be included in the <head> element. Code examples in the docs have been updated to reflect this change.false in the configuration.In this release, we’ve transitioned to an evergreen library URL for production environments: https://embedded-component.payabli.com/component.js.
To give our partners time to migrate to the new evergreen library, Payabli will continue to support version 1.9.0 of the library (https://embedded.payabli.com/1.9.0/component.js) until March 31, 2025. However, we’re no longer maintaining or adding enhancements to this version.
In the evolving landscape of web development, microfrontends have emerged as a powerful approach to building complex, scalable, and maintainable front-end applications. One of the key advantages of microfrontend architecture is its flexibility, particularly when it comes to versioning.
In traditional monolithic front-end architectures, versioning can be challenging, often leading to tightly-coupled systems that are difficult to update and maintain. This new architecture in which there is no hard versioning for the integrator allows our teams to unlock a range of benefits that enhance both development agility and overall system robustness. The new architecture offers these benefits:
Microfrontends allow individual teams to develop, deploy, and update their components independently. Without hard versioning constraints, teams aren’t forced to synchronize their releases with others. This autonomy leads to faster development cycles, as each team can push updates without worrying about breaking changes in other parts of the application. The result is a more agile development process, where new features and bug fixes can be rolled out quickly and efficiently.
When hard versioning is enforced, integrating different microfrontends often requires careful coordination, version management, and tedious backward compatibility checks. By removing hard versioning for the integrator, microfrontends can be deployed in a continuous delivery pipeline, making sure that the latest versions of each component are always available. This seamless integration reduces the complexity of deployments, allowing for a smoother and more reliable release process.
With no hard versioning, microfrontends can be updated incrementally, leading to more frequent and smaller updates. This approach minimizes downtime and reduces the risk of introducing major issues during updates. For users, this translates into a consistently improving experience, as they receive enhancements and new features without the disruptions that often accompany larger, versioned releases.
When issues arise in a versioned environment, rolling back changes or deploying hotfixes can become a cumbersome process, especially if dependencies between versions are complex. In a microfrontend architecture without hard versioning, bug fixes can be deployed directly to the affected component without needing to worry about maintaining strict version alignment across the entire system. This simplifies maintenance and also speeds up the resolution of issues, improving overall system stability.
One of the long-term benefits of avoiding hard versioning is the reduction of technical debt. In a traditional setup, maintaining multiple versions can lead to a cluttered and hard-to-manage codebase. Microfrontends, by nature, promote modularity and encapsulation, and when combined with a no-hard-versioning approach, they help keep the codebase clean and maintainable. Developers can focus on improving individual components without the overhead of managing complex versioning schemes.
We made enhancements to the embedded components to improve the tokenization process for some cards. Before, tokenization sometimes failed for cards if they weren’t being tokenized as part of a transaction. We’ve added two new keys to the tokenization request body: fallbackAuth and fallbackAuthAmount to run an authorization on cards while tokenizing them. See the configuration reference section of the embedded components docs for more details.
data-test as a configuration variable to the script tag. For example:<script src="https://embedded-component-sandbox.payabli.com/component.js" data-test></script>. This configuration variable shouldn’t be used with the production library.