Features

Billing improvements

• In the Add funding, Manage funding, and User verification widgets, the user can now set a default funding and billing account method right when the bank account is eligible.
• In the Manage funding widget, we have added clarity by explaining that the default funding account method will be used for their monthly account billing and as the default payables account for vendor payments.
• In the Add funding widget, the fundingAddSuccess event is emitted when the user successfully adds a new funding payment method. We have added the defaultBilling field to the bankData payload. This field is set as true if the bank account is set a default for billing and payments.

{
  bankData: {
    status: string;
    accountNumber: string;
    userVerificationRequired: boolean;
    id: string;
    nameOnAccount: string;
    defaultBilling: boolean;
  }
}

Miscellaneous

We have replaced overlay spinners with loading buttons across all the widget screens. This is a user experience improvement.

We have introduced a new feature for accepting or rejecting a Spend & Expense transaction in response to a 3D Secure challenge triggered to verify the identity of the cardholder.

New webhook for 3D Secure challenges

We have updated the webhooks events catalog to include the spend.three-ds-challenge.created event. Notifications are triggered for this event when a 3D Secure challenge is triggered for a Spend & Expense transaction. You can now set up subscriptions to receive notifications for the new event.

See Spend & Expense 3D Secure challenge notification payload for more information.

New v3 API endpoint for responding to 3D Secure challenges

We have a new API endpoint for responding to 3D Secure challenges for Spend & Expense transactions. With the Accept or reject a transaction (POST /v3/spend/transactions/{acsTransactionId}/3ds-challenge) request, you can respond to a webhook notification you receive when a 3D Secure challenge is generated for a transaction.

See POST /v3/spend/transactions/{acsTransactionId}/3ds-challenge in the API reference for more information.

The BILL v3 API Postman collection is another way for you to test with the BILL v3 API. Simply fork the collection from the Postman API Network and begin testing with different BILL v3 API workflows.

See BILL v3 API Postman collection for more information.

In the Record AP payment endpoint, we have introduced the capability of adding vendor credits. In the Record AP payment (POST /v3/bills/record-payment) request, you can now add vendor credits in the vendorCredits object.

See POST /v3/bills/record-payment in the API reference for more information.

Features

New Add vendor widget

The Add vendor widget enables users to add and manage vendors in the organization. With saved vendor information and vendor bank account information, users can pay vendors and bills. Users can also add and manage international vendors with this widget.

The Add vendor widget provides a set of features.

In the bills API endpoints, we have introduced the purchaseOrderNumber field. You can now set this field as a purchase order number linked with the bill.

See POST /v3/bills in the API reference for more information.

Vendor notifications

The vendor webhook notifications now include the shortName field. This field is the vendor short name. When you receive notifications for the vendor.created, vendor.updated, vendor.archived, or vendor.restored events, the notifications now include the shortName field.

See Vendor notification payloads for more information.

Bill notifications

The bill webhook notifications now include the purchaseOrderNumber field. This field is the purchase order number linked with the bill. When you receive notifications for the bill.created, bill.updated, bill.archived, or bill.restored events, the notifications now include the purchaseOrderNumber field.

See Bill notification payloads for more information.

Features

Onboarding widget improvements

• In the sign-up flow, we have made theming improvements in the UI elements.
• On the KYC/KYB screen, we have removed the empty list items in the Business type list.

MFA widget improvements

On the MFA setup screen, when the user enters and international (not US) phone number and selects Voice call to receive a verification code, we have ensured that the correct information banner is displayed on the screen.

Manage funding widget improvements

• When the user clicks Close in the user verification flow, we have ensured that the user is correctly navigated to the manage funding list screen.
• On the manage funding list and funding method details screens, we have made UX enhancements on how a funding method is displayed as default.
• On the funding method details screen, we have further simplified the bank account status values.

User verification widget improvements

• We have made UX enhancements on the identity questionnaire screen
• We have improved error handling in the user verification widget

In February 2025, BILL introduced UUIDs in the Spend & Expense API for further improving its security standards. All API responses include both id and uuid values.

As of July 9, 2025, the Spend & Expense id values are being deprecated. Both id and uuid values will continue to be available in all API responses. We strongly recommend that you use uuid instead of id in all your Spend & Expense API operations.

Webhooks Time To Live (TTL)

BILL maintains an event history for each subscription. We have now upgraded the webhooks TTL from 90 days to 180 days. You can get the list of event notifications sent to you for a subscription with GET /v3/events/subscription/{subscription_id}. You can now get the list of events for the last 180 days.

See Webhook API notification rules for more information about the complete set of rules.

Get list of event notifications improvements

We have added the capability for filtering event notifications by an entity ID. For example, to get notifications for a specific bill, you can now filter with the ID of the bill.

In the Get list of event notifications (GET /v3/events/subscription/{subscription_id}) request, you can now filter event notifications with the entityId field.

See GET /v3/events/subscription/{subscriptionId} in the API reference for more information.