Embedded Payments
May 29, 2026
Embedded Payments API Release Account v2.0.55 and Transaction v3.0.55
Account v2 and Transaction v3 Release for May 2026
| Feature name |
Description |
| Virtual transaction accounts |
- Virtual transaction account capabilities are now available, enabling platforms operating inside the flow of funds to accurately track amounts owed and settled with external parties.
- Create and manage virtual transaction accounts for efficient, scalable payments to a wide range of external parties.
- Transfer funds into and between transaction accounts for streamlined management of payment flows.
- Initiate payouts and collect payments from external counterparties without the need to onboard them.
|
April 24, 2026
Documents API Release v1.0.56
Documents API Release for April 2026
| Feature name |
Description |
| Documents APIs |
- A new Documents API has been introduced, enabling programmatic generation and retrieval of client documents such as account confirmation letters.
- Initiate document generation asynchronously via
POST /v1/documents. The API validates eligibility and returns a unique documentId upon acceptance.
- Download generated documents via
GET /v1/documents/{documentId}. Once the DOCUMENT_GENERATED webhook notification is received, the document is returned as a PDF file (application/pdf).
- Document types and eligibility: The
ACCOUNT_CONFIRMATION_LETTER type is supported for Commerce, Payment, and Processing accounts in OPEN or PENDING_CLOSE state.
- Webhook events: Two new events are published:
DOCUMENT_GENERATED: published when document generation completes successfully.
DOCUMENT_FAILED: published when document generation fails due to validation errors.
- Error handling: Structured error responses are supported, including HTTP status, code, title, field, message, and description.
|
November 12, 2025
Digital Onboarding API Release v1.0.18
Client Onboarding Changes for November 2025
| Feature name |
Description |
| Digital Onboarding APIs |
- Added Indirect Ownership Collection, enabling businesses to capture and declare both direct and intermediary beneficial owners for enhanced compliance and transparency during onboarding.
- Updated the description of the address lines field for Organizations Details to: “Post-office boxes (PO Box), private mail boxes (PMB), virtual office and registered agent addresses are not allowed. The address must be the principal place of business.”
- Updated the description of the Organization Type to: "This field specifies the legal classification of the organization and identifies whether the entity is a Corporation, Sole Proprietorship, Non-Profit, or Government Body. The values "
PARTNERSHIP" and "PUBLICLY_TRADED_COMPANY" are deprecated and should not be used."
- The allowed values for
organizationType have been revised. Following are the permitted organization types:
LIMITED_LIABILITY_PARTNERSHIP
LIMITED_PARTNERSHIP
GENERAL_PARTNERSHIP
LIMITED_LIABILITY_COMPANY
C_CORPORATION
S_CORPORATION
NON_PROFIT_CORPORATION
GOVERNMENT_ENTITY
SOLE_PROPRIETORSHIP
UNINCORPORATED_ASSOCIATION
- Fixed the broken Industry Descriptor Reference link for the Industry Category.
- Support for Publicly traded companies and Subsidiary includes the following additional fields:
isSubsidiary
publiclyTraded
tickerSymbol
stockExchange
stockExchangeName
Learn more about Embedded Payments and Commerce APIs.
- The size of the "city" field has been increased to 40 characters.
|
October 27, 2025
Embedded Payments API Release v1.0.34 and v2.0.34
Embedded Payments changes
Embedded Payment Changes
| Feature name |
Description |
| Accounts |
Account closure capability in Accounts API. |
| Webhooks |
New RECIPIENT_UPDATED event to notify on recipient record updates. |
Deprecated URLs
Embedded Payments API Release v1.0.27 and v2.0.27
Embedded Payments changes
Embedded Payment Changes
| Feature name |
Description |
| Recipients |
Pay-by-Card changes in recipient API. |
Embedded Payments API Release v1.0.26 and v2.0.26
Embedded Payments changes
Embedded Payments changes
| Feature name |
Description |
| All APIs |
Enable digital signature requirement for POST request payloads. |
Embedded Payments API Release v1.0.25 and v2.0.25
Embedded Payments changes
Embedded Payments changes
| Feature name |
Description |
| All APIs |
Description Digital signature annotations added (commented until UAT sync issues fixed). |
Accounts |
Optional closure reason on account closure, and new enum for MSS order notifications. Adjustments to routing code regex to allow for more international options. |
Embedded Payments API Release v1.0.24 and v2.0.24
Embedded Payments changes
Embedded Payments changes
| Feature name |
Description |
| Accounts |
Expansion of certain regex validations to support non-US accounts. Additional webhook models for Account V2 work, visible to the client, but they were not able to subscribe. |
Embedded Payments API Release v1.0.23 and v2.0.23
Embedded Payments changes
Embedded Payments changes
| Feature name |
Description |
| All APIs |
- Updates and fixes to mocks, and move mocks into this repo (client visible).
- Adjustment to server list to fix PayEdge routing for testing (not client visible).
|
Digital Onboarding API Release v1.0.17 and v1.0.16
New Digital Onboarding API Specification
Embedded Payments Changes
| Feature name |
Description |
| Digital Onboarding APIs |
- The
"Attester Full Name" field in the client section is now deprecated.
- The
"Document Types" field in the Document Request Response API is deprecated.
- The maximum length for the
"First Name" and "Last Name" fields in Individual Details has been increased to 40 characters.
- The description for the Government ID value has been updated, specifying that the Employer Identification Number (EIN) must consist of 9 numeric digits for the United States.
- The size of the Document Request ID has been increased to 30 characters.
|
| |
- The server domain and endpoints have been updated to utilize new routing endpoints.
- The IdempotencyKey has been introduced as an optional header for the following endpoints:
POST /v1/clients
PATCH /v1/clients/{clientId}
POST /v1/clients/{clientId}/verifications
POST /v1/document-requests/{id}/submit
POST /v1/documents
POST /v1/parties
PATCH /v1/parties/{partyId}
POST /v1/parties/{partyId}/validations
- Added response code 409 - Conflict to indicate a concurrent request has been detected.
- Added response code 422 - Unprocessable Entity to indicate that the request could not be processed due to semantic errors. Please refer to the error response for details.
- For the individualIds value field:
- A pattern has been added: ^[A-Za-z0-9-/.\s+&]*$
- A description has been added: "Please enter a valid Government ID value. SSN/EIN/ITIN must consist of 9 digits for the US. The length should be between 1 and 20 characters."
- For the organizationIds value field:
- A pattern has been added: ^[A-Za-z0-9-/.\s+&]*$
- In the
DocumentRequestRequirement object, the minRequired field's minimum value has been updated to 0 for items that are optional.
- The Document Upload request object has been updated to support multipart/form-data:
- File is a binary file.
documentData contains document metadata as a JSON object, e.g., {"documentType":"DRIVERS_LICENSE","documentRequestId":"50002"}.
- The following party fields have been marked as deprecated:
"Individual ID.Description"
"Organization Ids.Description"
"Individual ID.ExpiryDate"
"Organization Ids.ExpiryDate"
- The following individual details fields have been marked as deprecated:
"SocialMedia.ProfilePlatform"
"SocialMedia.UserName"
- The party field
"State" has an updated description: "The 2-3 character length state code should be provided in alpha-2 format, adhering to ISO-3166-2. State is mandatory in the US. In Great Britain, for example, the City of London would be LND. State would serve as Province in countries where applicable."
- The party field
"City" has an updated description: "City has a maximum of 34 characters. City would serve as County in countries where applicable."
- The following party fields have been marked as deprecated:
"Organization Details.WebsiteAvailable"
"ValidationResponse.Comments"
"ValidationResponse.Identities"
"Status"
|
April 30, 2025
Embedded Payments API Release v1.0.20 and v2.0.20
Embedded Payments changes
Embedded Payments changes
| Feature name |
Description |
| Webhooks |
A new event type of "ACCOUNT_UPDATED" has been added. A new event type of "RECIPIENT_ACCOUNT_VALIDATION" has replaced these following event types: RECIPIENT_READY_FOR_VALIDATION, RECIPIENT_READY_FOR_VALIDATION_EXPIRED, RECIPIENT_READY_FOR_VALIDATION_REMINDER |
March 31, 2025
Digital Onboarding API Release v1.0.12
New
New Digital Onboarding API Specification
Digital onboarding changes
| Feature name |
Description |
| API Specification |
API specification version 1.0.12 was released with minor field description changes.
|
March 12, 2025
API Release v1.0.11 (Digital Onboarding), v1.0.17 and 2.0.17 (Transactions). Including minor non-breaking updates from February release.
Updates Embedded Payments
Embedded Payments updates March 2025
| Feature name |
Description |
| Webhooks |
POST /v1/webhooks. Renamed eventType from ACCOUNT_RESTRICTIONS_UPDATED to ACCOUNT_RESTRICTION. The callback resourceType of type RESTRICTIONS has been removed. The events of this type were always related to accounts, and these events have been merged into resourceType ACCOUNTS. |
| Webhooks callbacks |
The RestrictionsCallbackEvent webhook callback model is deprecated. This has never been sent, and has been removed from the spec. Any account restriction information will come via the AccountCallbackEvent model. Associated with this, the resourceType value RESTRICTIONS is also deprecated. No impact. |
| Recipients |
GET /v1/recipients, POST /v1/recipients, GET /v1/recipients/{id}, POST /v1/recipients/{id} - The response property account/type became optional for all responses. GET /v1/recipients, GET /v1/recipients/{id} - The nested responses in the accountValidationResponse block now provide an optional description field, which will be populated with additional information in case the account validation result is negative. POST /v1/recipients/{id} - The validations on the field account.routingInformation.items.routingNumber have been updated to match the back-end validations. This field now has minLength of 1 (up from zero) and a regex of "^[0-9a-zA-Z]{3,13}$".
|
| Transactions |
POST /ef/v2/transactions - The validations on the field "recipient.account.routingNumber" have been updated to match the back-end validations. This field now has minLength of 1 (up from zero) and a regex of "^[0-9a-zA-Z]{3,13}$". |
Updates Digital Onboarding
Digital Onboarding updates March 2025
| Feature name |
Description |
| Clients and Parties default language |
POST /v1/clients and POST /v1/parties - the field preferences.defaultLanguage has been added as an option in both requests. |
| Documents and Document Requests |
You can now receive requests for additional documentation from your clients in the verification phase of onboarding. You can request details of the required documents using the Document Requests resource. You can upload the documents using the Documents resource. |
January 23, 2025
API Release v1.0.10 (Digital Onboarding - no updates), v1.0.14 and 2.0.14 (Transactions)
Updates
Feature changes to Embedded Payments API
Changes in version released on January 23, 2025.
January 2025 updates
January 2025 updates
| Feature name |
Description |
| Recipients |
The accountValidationResponse field in the response model of these endpoints used to specify minItems: 1' and this has been reduced to minItems: 0 in the following endpoints: GET /v1/recipients, POST /v1/recipients, GET /v1/recipients/{id}, POST /v1/recipients/{id} |
| Notifications |
Webhook callback event specs have been updated, without changing the models, to facilitate client-side code generation of the callback models. If you were using your own hand-crafted models for the webhook events, you will not be impacted. If you were using codegen, this should make the resulting objects easier to use. |
| Clients |
Webhook callback (event) specs have been updated (without changing the models) to facilitate client-side code generation of the callback models. If you were using your own hand-crafted models for the webhook events, you will not be impacted. If you were using codegen, this should make the resulting objects easier to use. This affects the following endpoints: POST /ef/v1/clients, POST /ef/v1/clients/{id}. |
December 20, 2024
API Release v1.0.10 (Digital Onboarding - no updates), v1.0.13 and 2.0.13 (Transactions)
Updates
Feature changes to Embedded Payments API
Changes in version released on December 20, 2024.
December updates
| Feature name |
Description |
| Error handling |
Error codes and definitions have been updated. Check error codes documentation for more details. |
| Transactions |
The response property amount became optional for the status 201. |
| Recipients |
In the OAS, the description of address fields was updated to address a discrepancy with the maxLength property. |
November 18, 2024
API Release v1.0.10 (Digital Onboarding), v1.0.12 and 2.0.12 (Transactions)
New
Feature changes to Embedded Payments API
Changes in version released on November 18
| Feature name |
Description |
| Transactions |
You can now make payments using RTP and Wire transaction types. To ensure this is possible, you must add the relevant routing and address information for your client's linked account. You can also update existing linked account details to include RTP and wire routing information. |
| Transactions |
POST /ef/v2/transactions - changed the pattern of the request property "transactionReferenceId" from "^(.|\s)*\S(.|\s)*$" to "[_0-9A-Za-z]+".
|
November 4, 2024
API Release v1.0.10 (Digital Onboarding), v1.0.10 and 2.0.10 (Transactions)
New
Feature changes to Embedded Payments API
| Feature name |
Description |
| Webhook subscriptions |
New recipients notifications:
READY_FOR_VALIDATION
RECIPIENT_READY_FOR_VALIDATION_REMINDER
RECIPIENT_READY_FOR_VALIDATION_EXPIRED
|
| Request direct debit |
You can now request direct debit payments from your clients if you pay them directly (without creating an account for them). |