---
title: v2.37.0 (Winter '26)
slug: payments/v2370-winter-26
createdAt: 2025-12-01T18:38:52.875Z
---

This release focuses on improving performance for high-volume customers, enabling richer payment data for reduced processing costs, expanding global bank payment options via Stripe, and completing rebranding from Asperato to Unaric Payments.

:::CtaButton{label="Install v2.37.0 (Winter '26) Package" externalHref="https://login.salesforce.com/packagingSetupUI/ipLanding.app?apvId=04tJ70000004nx3IAA" openInNewTab="true"}

:::

## Unaric Payments rebranding

We’re pleased to confirm that the **Asperato One **app has been rebranded to **Unaric Payments**. This includes:

- **Updated application name**
- **New Unaric logo**
- **Updated tab names**
- **Updated object & field labels**
- **Updated permission set names**
- **Updated help text and descriptions**

:::hint{type="info"}
API names are not affected by this rebranding update and will remain the same.
:::

### On new installs

All rebranding updates are applied automatically.

### On upgraded orgs

All object and permission set name updates are applied automatically. However, due to Salesforce limitations, the following items **must be updated manually** after upgrade:

- **App name**: Needs to be refreshed.
- **Help text on fields**: Needs to be updated by the system administrator.

Updating the app name follows the standard method for most Salesforce apps:

1. On Salesforce, navigate to **Setup >** **App Manager**.
2. Find the Asperato One app (*AsperatoONE\_Lightning *as **Developer Name**) in the list.
3. Click the **dropdown arrow** on the far right of the app row and select **Edit**.
4. In the **App Details **section, update the **App Name**. You can also update the description and app branding image.
5. Click **Save **to finish.

## New feature: Level 2 & level 3 data processing (Stripe Connect)

Winter 26 introduces level 2 and level 3 (L2/L3) data processing via **Stripe Connect**, enabling clients to send enriched transaction data to Stripe and potentially qualify for reduced interchange fees. This is particularly beneficial for US-based organisations, where L2/L3 data directly impacts processing costs.

Previously, only level 1 (basic) payment data was passed to the PSP. With this change, you can now include line-level information such as:

- **Product name**
- **Product code**
- **Tax amounts**
- **Unit cost**
- **Quantity**
- **Unit of measure**

### Processing behaviour

- *If **Payment Line Items** exist*, level 2 / level 3 data is sent to** Stripe**.
- *If no line items exist*, payment is processed as level 1 only.

:::hint{type="info"}
No system error is generated when line items are missing.
:::

### What’s included

- New object: **Payment Line Item** (child of **Payment**).
- Support for L2/L3 data on single payments.
- New packaged permission set for line-level data.

::Image[]{src="https://api.archbee.com/api/optimize/10Nod6Ww95R3dPr0k0TCJ/TX5wgs2YZXRqwYVESZfoh_image.png" size="66" width="983" height="768" position="center" caption=""Payment Line Item" is a child object of "Payment". Existing customers are unaffected by this new object." darkWidth="983" darkHeight="768" showCaption="true"}

### What’s not included

- Recurring/scheduled payments are **not supported** in this release
  (i.e. payments processed via Authorisations).
- No Certinia connector changes are included. The Certinia connector does **not** create Payment Line Items automatically. As such, clients must populate** Payment Line Items** via Flow or custom automation.

### Important notes

- This is a **premium feature** and requires enabling with your CSM before use.
- Only available via **Stripe Connect** for **card payments.**
- Clients should work directly with Stripe to confirm:
  - Which data is being received.
  - How their transactions are classified.
  - What discounts may apply.
- Stripe does not clearly display the value of L2/L3 data inside the dashboard, so coordination with Stripe is essential.

### Prerequisites

- Speak to your CSM about enabling L2/L3 data access. 

## Scalability improvement: Reduced Salesforce API usage

Significant backend optimisations have been made to API usage. Payments are now batched in API calls, reducing their total number in Salesforce for high-volume clients**.**

Previously:

- \~2.48 API calls per payment

Now:

- \~0.248 API calls per payment (batch size of 10)

This allows **Unaric Payments **to:

- Stay well within Salesforce’s 24-hour API limits
- Support large-volume clients more reliably
- Reduce the need for expensive API limit increases

No action is required from customers for this improvement.

## Expanded Stripe bank payments

Winter 26 expands bank payment support via **Stripe**, using **Stripe Hosted Checkout Elements**.

### Now supported

- BECs – Australia
- Direct Debit – United Kingdom
- SEPA – Europe
- BECs – New Zealand

### *Coming soon*

- ACH – United States
- PAD – Canada
- Payout processing for bank payments

### Important differences

- Requires **customer email address** for Stripe session creation.
- Styling is partially controlled by Stripe (not fully customisable).
- The experience is functionally the same but **visually different** from the existing pay page.
- All outcomes, errors and statuses flow back to Salesforce as normal.

Customers must configure some options within their **Stripe Dashboard**.

## Cybersource security update

Cybersource has introduced new OAuth security requirements. All clients using Cybersource must **re-authenticate before 31 March 2026**.  If you are an existing Cybersource client you will have been notified of what changes you need to make by our CSM Team already.  For new clients using Cybersource, you will be unaffected by these changes as you will automatically use the new connection.

### Required steps

1. Remove the existing Cybersource PSP connections.
2. Add new PSP connection to Cybersource one mode at a time to ensure the paypage remains active and isn't lost.

:::hint{type="warning"}
## Important notice for clients using guest user access to Unaric Payments

We’re aware that some clients have been using Guest Users with our package. Guest Users have never been an officially supported use case and whilst certain functionality may have worked in the past, this was not by design and won't be guaranteed going forward. With the versions Summer 25 and onwards, our enhanced security controls in line with Salesforce best practices may affect existing Guest User configurations. We would advise clients to carefully check before upgrading any integration with us which uses Guest Users.  Our recommended approach is to use Experience Cloud (community) user licenses, which are fully supported, secure, and fully compatible with protected package components.

Contact support at [support@unaric.com](mailto\:payment-support@unaric.com) if you have any questions or concerns.
:::

:::hint{type="danger"}
## Important notice on Certinia Connector: Version dependencies for the Winter 26 upgrade

The Winter ’26 releases of Unaric Payments and Certinia are **interdependent**. This is primarily due to the rebranding from *Asperato* to *Unaric Payments*, which introduces:

- Updated naming conventions 
- New feature configurations 
- Required changes to existing setups 

You must follow Unaric Payments and Certinia upgrade guides to ensure a successful transition.
:::

### Upgrade Certinia

The Certinia upgrade directly impact payment processing. Within the latest Certinia upgrade guide (available at [Upgrading to Accounting Winter 2026](https://help.certinia.com/main/2026.1/Content/Accounting/Release/UpgradeGuide/UpgradingFeatures.htm)), you must follow the instructions under **[Asperato is now Unaric](https://help.certinia.com/main/2026.1/Content/Accounting/Release/UpgradeGuide/UpgradingFeatures.htm#:~\:text=Asperato%20is%20Now%20Unaric)** section, specially those in the **[Enabling the Vendor Payments Customizations Feature](https://help.certinia.com/main/2026.1/Content/UnaricPaymentsConnector/InitialSetup/OutboundVendorPayments/VendorPaymentsCustomizations.htm)** page. Although this section is labelled for vendor payments, it also includes required steps for inbound collections, which should not be overlooked.

### Feature Console: Required Actions

1. Within Certinia, navigate to **Feature Console > Vendor Payments Customizations. **The Feature Console may appear as *complete*, but additional steps have been added within it.
2. Click into the feature (do not rely on the summary view).
3. Review and complete all newly introduced configuration steps. 

### Critical configuration changes

To ensure collections continue working, apply the following configuration changes:

::::WorkflowBlock
:::WorkflowBlockItem
**Update payment provider**

- **Deactivate:** *Asperato* 
- **Activate:** *Unaric* 
:::

:::WorkflowBlockItem
**Update existing Payment Integration Methods (PIMs)**

- Edit every existing PIM record 
- Replace *Asperato* with* Unaric* 
:::

:::WorkflowBlockItem
**Review and update automation (flows / processes).**

If you have automations place with Salesforce Flows, Process Builder, or other custom automation, ensure they:

- No longer reference *Asperato* 
- Correctly populate PIMs with *Unaric.*
:::
::::

### Common issues to watch for

After upgrading, check for:

- Failed inbound collections 
- PIMs still referencing *Asperato* 
- Automation populating outdated values 
- Feature Console steps left incomplete