You can now generate a developer key in the BILL web app to work with the BILL API. As an administrator of your test organization, you can generate up to 4 developer keys.
We learned that the user was able to submit the verification form without providing the complete address. We have now fixed this issue. We ensure that the address information is available and complete before the user can submit the verification form.
Vendor Search and Invite widget
We learned that the user was able to re-submit the vendor bank details form with keyboard navigation. We have now fixed this issue. Keyboard navigation for re-submitting the form has been disabled.
Manage funding widget
We have fixed minor styling issues on the payment methods and bank details screens.
Miscellaneous
We learned that banners added extra space at the bottom of all the widgets. We have now fixed this issue.
The webhook notification payloads for all bill-related events now include all the response fields for the bill. For example, if you have subscribed to the bill.updated event, the payload for each related notification will now include all the response fields for the each updated bill.
We have updated the webhooks events catalog to include the payment.failed event. When your Create a payment (with POST /v3/payments) or Create a bulk payment (with POST /v3/payments/bulk) request fails, BILL sends you a notification with information to identify your payment request and with error messages to help you debug.
You can now set up subscriptions to receive notifications for the new event.
BILL is introducing UUIDs in the Spend & Expense API. Each ID value that uniquely identifies an entity in Spend & Expense (such as a budget, transaction, or user) now follows the UUID4 format.
UUID v4 (or UUID4) is a randomly-generated 128-bit identifier and is highly secure. The introduction of UUIDs in the Spend & Expense API is another measure taken by BILL for further improving its security standards.
Spend & Expense webhook notifications
When BILL sends notifications for the spend.transactions.updated event, each ID in the notification payload is a UUID value. For example, uuid is the UUID of the transaction, and userUuid is the UUID of the user that created the transaction.
While the spend.transactions.updated notification payload includes only uuid values and no id values, the Spend & Expense API responses continue to present both uuid and id values.
In the future, the Spend & Expenseid values will deprecated. We will share more information when we have a timeline for this deprecation.
GET operations
Let's use the example of budgets to understand the impact of introducing UUIDs on the Spend & Expense GET operations.
When you get details about a budget with GET /v3/spend/budgets/{budgetId}, you currently set the budget id in your API request. Moving forward, you can set the budget uuid as another method for getting details about a budget.
GET response fields
For each existing Spend & Expense API object, BILL has generated a uuid value for each id value. In the GET /v3/spend/budgets/{budgetId} response example, both the uuid and id values are available to uniquely identify the budget.
Similarly, for fields with an id suffix, we now have the same field with the uuid suffix to present the UUID value. For example, for the parentBudgetId field in the API response for a budget, we now have a additional parentBudgetUuid field to present the UUID of the parent budget.
Currently, you cannot use UUID values in the Spend & Expense POST, PATCH, PUT or DELETE operations. This feature will be available in the future. We will share more information when this feature is available.
In the payments API response, we have introduced two new fields in the rppsDisbursement object.
Field
Description
traceNumber
Payment trace number. This value is used to uniquely identify a payment in a batch.
batchNumber
Payment batch number
In addition, we have introduced a new disbursementStatus field in the response to provide the payment disbursement status at each stage of the payment.
When the partner triggers the user verification widget for a user that does not have an active, verified bank account, we now inform the user that they are not required to complete their identity verification.
When Google Places fails to load for the address field, we enable the user to manually enter address information and continue. In this case, we now ensure that Google Places does not throw unhelpful validation errors to the user.
Onboarding widget improvements
On the KYC/KYB screen, we have added a spinner to ensure that Google Places is available for the user when they are using the address field.
When the user bank account is added manually, we have added a spinner on the end state screens to provide a cleaner experience. This improvement disables the ability to click multiple times while the partner integration listens to the BILL success events and navigates back to the partner experience.
Features in the next release
Usability improvements in the Convert to ePay widget