> This is Payabli documentation. For a complete page index, fetch https://docs.payabli.com/llms.txt — append .md to any page URL for lightweight markdown. For section-level indexes, query parameters, and other AI-optimized access methods, see https://docs.payabli.com/ai-agents.md

# Embedded Components changelog

This changelog covers updates to the Payabli embedded components.

## July 24, 2026

# Changes for July 24, 2026

## Corrected Google Pay button style accepted values

We've corrected the documented `buttonStyle` values for Google Pay in the [ExpressCheckout UI component configuration reference](/guides/pay-in-components-express-checkout#configuration-reference). The accepted values are `black`, `white`, and `default`, with `black` remaining the default. This change affects the documentation only — the component's accepted values haven't changed.

## July 10, 2026

# Changes for July 10, 2026

## Enhanced Apple Pay support for ExpressCheckout UI

The ExpressCheckout UI component can now support Apple Pay in third-party browsers.
To enable Apple Pay in third-party browsers (like Chrome and Edge), you need to enable the `crossBrowser` field in the `applePay` config object of the ExpressCheckout UI component.
You must also verify your domain with Apple Pay and ensure that your website's CSP allows the Apple Pay SDK script to load.
To learn more about enabling Apple Pay for third-party browsers, see [Apple Pay compatibility](/guides/pay-in-components-express-checkout#apple-pay-compatibility)

## June 15, 2026

# Changes for June 15, 2026

## New `invoiceData` object for ExpressCheckout UI

We 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](/guides/pay-in-components-express-checkout#configuration-reference) for more information about the `invoiceData` object.

## May 11, 2026

# Changes for May 11, 2026

## New `mode` field for ExpressCheckout UI

We 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 transactions
* `autopay` - sets up recurring subscriptions with a billing schedule
* `tokenization` - tokenizes payment method without charging customer

See [ExpressCheckout UI](/guides/pay-in-components-express-checkout#use-cases) for more information about the use cases supported by the ExpressCheckout UI component.

## New `saveIfSuccess` field for ExpressCheckout UI

We 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](/guides/pay-in-components-express-checkout#use-cases) for more information about the `saveIfSuccess` field.

## April 15, 2026

# Changes for April 15, 2026

## Retirement of the Embedded Components Playground

Payabli's Embedded Components Playground has been retired as of April 15th, 2026.
The site at `playground.payabli.com` is no longer available.

### Why the playground was deprecated

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.

### What's available instead

The documentation already includes tools that cover most of what the Playground offered:

* **Live demos** — interactive, embedded demonstrations of the embedded components
* **Code walkthroughs** — detailed, step-by-step guides to integrating and using each component

These resources are available now. See the [Embedded Components overview](/guides/pay-in-components-overview) for more information.

## March 16, 2026

# Changes for March 16th, 2026

## New `splitFunding` config for ExpressCheckout UI

We 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](/guides/pay-in-components-express-checkout#configuration-reference) for more information.

## February 17, 2026

# Changes for February 17, 2026

## New input field for RDC payment method in EmbeddedMethod UI

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](/guides/pay-in-components-embeddedmethod-ui#configuration-reference) for more information.

## October 6, 2025

# Changes for October 6, 2025

## New RDC payment method for EmbeddedMethod UI

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](/guides/pay-in-components-embeddedmethod-ui#configuration-reference) for details on how to configure EmbeddedMethod UI with RDC.

## Optional ExpressCheckout UI transaction details

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:

* **Complete transaction metadata**: Parent organization, paypoint information, gateway transaction IDs, batch details
* **Detailed payment data**: Masked account information, account type, expiration, holder name, BIN data, and payment breakdown
* **Transaction processing details**: Response codes, AVS and CVV responses, authorization codes
* **Customer information**: Complete billing and shipping address details, customer status, and custom identifiers

This config allows you to retrieve transaction information without making a separate API call.

See the [Pay In Transaction integration guide](/guides/pay-in-developer-transactions-create#includedetailstrue-response) for a complete example of the `transactionDetails` object structure and usage.

## January 28, 2025

* Added the ability to use special characters ('á', 'Á', 'é', 'É', 'í', 'Í', 'ó', 'Ó', 'ú', 'Ú', 'ü', 'Ü', 'ñ', 'Ñ') in the embedded components. The HTML element `<meta charset="UTF-8">` must be included in the `<head>` element. Code examples in the docs have been updated to reflect this change.
* Fixed a bug where the embedded components would not show a card network as "not allowed" even though the card network was set to `false` in the configuration.

## October 27, 2024

## Evergreen library URL

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.

#### Read our reasons for going evergreen

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:

#### Increased flexibility and autonomy

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.

#### Seamless integration and deployment

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.

#### Enhanced user experience

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.

#### Simplified maintenance and bug fixes

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.

#### Reduced technical debt

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.

## Other enhancements

* Added enhancements for the ExpressCheckout UI.
* Added better custom CSS handling for some components.

## October 24, 2024

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.

## July 31, 2024

## Enhancements

* Added enhanced sandbox support for testing embedded components. Now, when using an embedded component in the sandbox environment, you must add `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.
* Added support for alphanumeric account holder and cardholder names in embedded components.
* Added support for different ZIP code formats.

## Bug fixes

* Fixed an issue that caused the ACH and card forms to disappear when a user clicks on certain areas of the form. The forms now display as expected.
* Fixed an issue with card expiration date validation.