Feature

Tokenized and saved CVV on credit card payment methods as single-use values to enhance security during transactions.

Feature

Enabled handling of message status update metadata received through SNS (Simple Notification Service).

We have some upcomming deprecations or system changes that could have an impact on implementations or expectations. So below are a list of changes along on or after dates for when the change will take place.

After July 1st, 2025

transaction.paymentMethodId removal

This attribute has not been included in documentation for quite some time, but is being provided for webhook payloads and GET operations to load a Transaction. The paymentMethodId attribute is a duplicate of paymentMethod.id so please use that value instead.

Webhook timeout: 15

Subscriptions for webhooks allow a timeout of 30 seconds and it will be reduced down to 15 seconds.

After August 1st, 2025

Business Processes with Opted Out Addresses

If a Business Process has an opted out Address (a messaging concern) it will no longer impact the creation of a Business Process. It will continue to create but messages will not deliver. Since there are multiple ways to get a Customer to a Business Process this will open the door to more use cases.

After October 1st, 2025

Merchant Mock Products

When you create a merchant you have mock products created and enabled by default. We are going to remove this behavior as it is generally not a prefered behavior. You are likely already removing these products and if so, make sure your code is updated to be friendly to an empty array for the product list.

Address type

When an address is being provided across a few endpoints, the type is also optional and ignored. It will continue to be returned, but we will no longer accept it.

Feature

Expanded the list of allowed headers for messages to support additional metadata handling.

Bug Fix

Enabled CORS support on file-related endpoints to ensure proper cross-origin access.

Bug Fix

Updated performance test logic to resolve failure during QA validation.

Audience: Developers consuming transaction via webhooks and GET operations
Effective: June 30th 2025 July 8th, 2025

What's Changing

The status attribute in transaction objects is being updated to a more descriptive, lifecycle-aware model. This change is required to support a range of upcoming features and enhancements, and may necessitate updates to your current integrations.

Only transactions created after the release will return statuses from the new list. Older transactions will continue to return their original statuses, such as APPROVED.

Why This Matters

These status updates enable several powerful new capabilities coming to the platform, including:

• Separate APIs for Authorization, Capture, Void, and Refund — allowing for more precise control and visibility.
• Apple Pay and Google Pay support — expanding the ways customers can complete payments.
• Transaction synchronization — the ability to bring external transactions into the Authvia platform for unified visibility and management.
• Expanded status tracking — including new states like Settled and Funded to better reflect transaction progression.
• Batch processing support — submit and process transactions in bulk via FTP or API.

These features are part of a broader platform enhancement initiative. Full release notes will be shared at launch, but immediate action may be required to ensure compatibility with the new status model.

Current Values:

'AUTHORIZED' | 'APPROVED' | 'DECLINED' | 'ERROR' | 'FAILED' | 'NOT AUTHORIZED' | 'PAYMENT-IN-PROGRESS' | 'PROCESSING'

New Values:

Note: Transaction actions and statuses are likely to be added to in the future, to support additional capabilities. Additional details on statuses and FAQ can be found here.

What You Need to Do

• Review and update any client logic that parses or reacts to the status field.
• Ensure all webhook handlers and GET consumers can accommodate the new values, and possible future values.
• Update your webhook subscriptions to be specific to your current needs. See Use Webhook Conditions.

⚠️ This is a read-only field — it is never supplied by clients, only received from our platform.

Use Webhook Conditions

With the introduction of more granular transaction statuses, additional webhook events will be published. To avoid processing unnecessary events, you must update your webhook subscriptions to include filters that limit notifications to only the statuses your system requires. See the Create Webhook Subscription documentation for implementation details.

Temporary Backward Compatibility

For 90 days following the release, the platform will continue to announce the APPROVED status for CHARGE transactions that reach the CAPTURED state. This temporary overlap is intended to provide a longer runway for systems currently listening for APPROVED webhook events. After the 90-day period, this behavior will be removed, and systems must transition to using the updated status model.

July 9th, 2025 we updated this solution to also send APPROVED for PAIDOUT, VOIDING and REFUNDING statuses (and the corresponding actions) as well.

For questions or migration guidance, contact [email protected]

We have updated the payment-method action to enhance clarity and functionality:

Key Changes

• Parameter Renaming: The parameter previously known as restrictDefault has been renamed to defaultSelectionAllowList to better reflect its purpose.
• Logic Adjustment: The functionality has shifted from an exclusion list to an inclusion list. Now, only the payment methods specified in the defaultSelectionAllowList will be considered for default selection in user settings.

Impact

• Default Payment Method Selection: When a business process includes a payment-method action with a defined defaultSelectionAllowList, only the specified payment methods will be eligible for default selection in user settings. If a user's default payment method does not match the allowed list, it will not be set as the default for payment.
• Optional Parameter: The defaultSelectionAllowList parameter is optional. If not provided, all available payment methods may be considered for default selection.
• Validation: When creating a payment-method action, ensure that the values specified in the defaultSelectionAllowList align with the supported payment method types. Invalid entries will result in an error.

For detailed implementation guidance and further information, please refer to our API Documentation.

We are pleased to announce the following updates to our messaging service:

MMS Messaging with Attachments

Merchants can now send MMS messages with attachments through the messaging service. To utilize this feature, ensure that an MMS product is configured for your merchant account. The catalog of all providers we support for mms messaging is located here, along with instructions on setup.

Sending Messages to Unregistered Addresses

The messaging service now supports sending messages to recipients not previously registered in the database. This enhancement allows for greater flexibility in reaching new customers.

Added the blueprint key to the payload of Business Process webhooks for Business Process Create and Business Process Update events.

• Provides the blueprint ID to help track and associate business processes with their corresponding blueprints.
• Improves integration workflows by ensuring more detailed and contextual data is available.

https://developer.authvia.com/v3.3/reference/business-process-created-webhook

https://developer.authvia.com/v3.3/reference/business-process-updated-webhook