- REST APIs
- Welcome
- Cards
- 3D Secure 2
- Vault
- Getting Started
- Using the API
- Typical API Calls
- Verify That the Service Is Accessible
- Create a Profile for a Customer
- Add an Address to a Profile
- Add a Card to a Profile
- Add a Bank Account to a Profile
- Create an Apple Pay Single-Use Token
- Create a Google Pay Single-Use Token
- Create a Mobile Single-Use Token
- Create a Direct Debit Single-Use Token
- Process a Transaction Using a Payment Token
- API Reference
- Test and Go Live
- Direct Debit
- Apple Pay
- Google Pay
- Alternate Payments
- Platforms
- Overview
- Accounts API V2
- Account Management
- Getting Started
- Using the API
- Typical API Calls
- Verify That the Service Is Accessible
- Create a New Merchant
- Create a New Merchant Account
- Create a New User
- Add an Address
- Create a Business Owner
- Add a Business Owner Address
- Add a Business Owner Identity Document
- Add a Merchant Bank Account
- Accept Our Terms and Conditions
- Activate the New Merchant Account
- Validate the Bank Account
- Enable Webhooks to Receive Application Statuses
- Test and Go Live
- Subaccounts
- Split Payouts
- Balance Transfers
- Paysafe Payments API
- Reference Information
- SDKs
- Mobile SDKs
- Additional Documentation
- Resources and Support
- Shopping Carts
- Classic APIs
- Glossary
Integration Principles
API Versions
The API version will influence the request and response object structures as well as the functionality that is available through the API. A new version of the API will be introduced only if we roll out a backwards-incompatible change that may impact your existing integrations. You can manage when to upgrade to the latest version, helping ensure your integration is not disrupted as new functionality becomes available.
Major Version
The major version (i.e., /v1/ ) represents a major technology shift between versions of the API. Changes in the major version are reserved for large-scale changes to the API that fundamentally change integration requirements from the previous version. Modified business domain models, re-design of functional flows, or change in API resource patterns are all considered major changes. Changes to a major version are rare and typically require an extended deprecation cycle (~2 years) from prior versions to allow all consumers of the API to adapt.
Backwards Compatibility
Your integration should take the following backwards-compatible changes into consideration so as not to break when additional fields are added to the API.
What Is Considered a Backwards-compatible Change?
- Adding API resources or adding new properties to existing API resources
- Modifying the order of parameters or JSON object elements
- Adding optional request parameters to API methods
- Adding a webhook event type
What Is Considered a Backwards-incompatible Change?
- Removing an API resource
- Removing an API resource's object attribute
- Changing required parameters or JSON object elements
- Removing previously supported API calls