Welcome
PEX is a commercial prepaid card that helps your company control employee spending. You can issue cards, add funds to cards, and apply spend controls (including restricting specific merchant categories) through our Admin portal which includes 24/7 access to your PEX account as well as mobile support.The PEX platform is also available through a complete set of JSON-based APIs which can be used to duplicate every feature available in our Admin portal, and to support a few features that aren’t. The PEX platform can be used to power any proprietary expense management or business payment application to create a seamless payment experience for your users.
Starting with the PEX APIs
PEX offers a collection of APIs to support integrations with a variety of use cases, including Card Funding and Reporting. Customers are provided with a sandbox environment to familiarize themselves with the PEX APIs. The sandbox environment offers the opportunity to explore all API calls before working with production APIs.PEX SDK for .NET
For easier access to our APIs PEX offers a open sourced SDK for .NET on Github. The PEX SDK for .NET provides access to the PEX platform via the REST API. Please sign up on PEX Developer Platfrom to explore the SDK for .NET.Authentication
PEX API uses HTTP Authentication to authorize the incoming requests. The standard Authorization header is used for holding the Authorization tokens. Please refer to the API documentation on the /Token endpoints for further information on token management.PEX also provides OAuth as an option for authentication.
Overview of the PEX API
The PEX APIs are organized into 8 groups, each relating to an area of functionality.Establishing the Business Account
After your company completes the PEX enrollment process and service agreement acknowledgement, PEX will set up a business account. Your business account is used to store funds that will later be assigned to card accounts and used as payment for company expenses.Working with Card Accounts
Once your business account has been created and funded, you are ready to begin creating card accounts.Response Codes
PEX uses conventional HTTPS response codes to indicate the success or failure of a request. In general, 200-level codes indicate success, 400-level codes indicate an error that resulted from your input, and 500-level codes are typically related to a PEX internal issue, and should be reported to us. Errors specific to a call are included on the documentation page. Global errors can occur with most calls and they are listed below:- 400: The request is invalid
- 401: Password has changed
- 401: Token expired or does not exist
- 401: Missing authorization header
- 401: Bad authorization scheme
- 401: Invalid appId
- 403: Must be admin user
- 403: Business is not open
- 403: User is not active
- 403: Invalid Card Account ID
- 409: Conflict
- 429: Usage limits exceeded
- 500: System error
- 502: Bad Gateway; please retry after 2 mins
If 400: Invalid Input is received, further helpful information about the error is provided in the response.
Rate Limits
In order to assure consistent, reliable service for all of our customers, all API users are subject to an overall limit of 120 calls per minute. Certain APIs have individual limits:| GET/Details/TransactionDetails | 1 hit per minute |
| GET/Details/AccountDetails | 10 hits per hour |
| GET/Details/AllCardholderTransactions | 10 hits per hour |
| POST/Bulk/Zero | 2 hits per day |
| POST/Card/Zero/{Id} | 1 hit per 4 mins for same card account |
| POST/Business/OneTimeTransfer | 2 hits per hour |
| POST/Token | 2 hits per day |
| DELETE/Token | 2 hits per day |
If you exceed any API limits, you will receive error 429: Usage Limits Exceeded. Please contact your API support manager for work-arounds and help if you are receiving error responses related to Usage Limits Exceeded.
Backward Compatible Changes
We strive to avoid any changes that would break API calls, but we will make changes over time that may result in changes to the data that you pull from PEX.
We consider the following changes to be backwards compatible:
- Adding new API endpoints
- Adding new data elements to existing response schemas
- Adding new webhooks
- Changing the length or content of any API identifier
