API Basics

 

WePay’s API products are packed full of features and conveniences to help you handle different scenarios, like reducing PCI scope, preventing double charges in case of error, and adding in your own custom data to help maintain things like state. This page is a full list of features to use depending in your use case – keep it handy.

By the end of this doc, you’ll have the the right information to build an API call.


API Headers

 

As with all API calls, you need to pass required headers. First, let’s cover the required headers for all API calls to WePay, across products. As a reminder, you created your API credentials during account sign-up. Access them here.

Header Key Header Value (example)
App-ID 123456
API-Version 3.0
App-Token stage_MzBfNzM2ZmEwYTItZmQ1My00MYg1LEEwYmMtYzE2MmMzNDIyZDIz
content/type application/json

In order to safely retry payment (/payment) or refund (/refunds) calls, you need to use the “Unique-Key” header, which is a uniquely defined value. Read the Idempotency section below for more information.

Additionally, the “Client-IP” and “WePay-Risk-Token” headers are required on the following endpoints if your platform is not using the WePay JS for tokenization:

Note

If you’re sending the WePay risk headers on the above server to server requests (as opposed to using the WePay JS), please be sure to follow our Server to Server Integration guide for Clear.

Finally, look to the table below to see the base URLs you will interface with. All resources found on the API reference are appended to the base URLs.

Base URL Environment
https://stage-api.wepay.com Stage
https://api.wepay.com Live

API Versions

 

When interfacing with the WePay API, you can select which API version to pass. API versions are compatible with other versions, so you could make a call to certain endpoints using v3.1, and to others as v3.0.

If you do not need to use different versions, it’s completely fine to use a single version. The latest version is 3.0.


API Rate Limits

As a default, we have a rate limit across endpoints of 30 requests per 10 seconds. If you have a business use case that requires a higher rate limit, please speak to your account manager or API Support, at api@wepay.com.


Permissions Based Features

 

When roadmapping your integration with WePay, it’s important to remember that certain endpoints and parameters require permission for use. Sending calls to restricted endpoints or with restricted parameters will result in the following error:

{
	"error_code": "NOT_AUTHORIZED",
	"error_message": "FEATURE_NOT_ENABLED_FOR_APPLICATION"
	...
}

During your planning, take note of each feature you’d like access to and submit a request to your account manager, technical account manager, or WePay’s developer support (api@wepay.com). Your request should include:

  • Your platform's stage app-id
  • A high-level description of your business
  • Your business use case for the specific feature(s) being requested

Restricted Features

 

Resources Endpoints Parameters Notes
Accounts POST /accounts; POST /accounts/{id} beneficiary_legal_entity_id  



Errors

 

WePay’s API follows standard API conventions with errors. You can view the Clear API reference documentation for an exhaustive list of error codes (Link API reference coming soon). Throughout the integration guide, we will also highlight special errors and remediation strategies.


Idempotency

 

WePay’s API is designed to be idempotent. Making GET calls will not modify resources, and sending a POST to an object will update the fields provided in the POST body. If you’d like to delete a field in an object, send a POST with the field set to NULL. For complex objects, like beneficial owners, where you may not have all data at once, pass an empty object, like {}, to continue building out the Legal Entity object, and update it when you have the inner fields.

In error scenarios, retrying a payment and refund can lead to overcharging a payee or drawing too much from a merchant. In order to safeguard against these scenarios, you will use the “Unique-Key” key in your request header, and a unique value, generated by you. You can use any value for the Unique Key, as long as it’s unique.

As an example, let’s say your platform handles rent between landlords and tenants. A good unique key could be the tenant’s payment date, so that double payments do not occur.

For all POST calls made to /payments and /refunds, you are required to send “Unique-Key” in the header. For all other POST calls, it is optional. In general, Unique-Key is valid for 24 hours.


Custom Data

 

Custom data refers to a key-value object that can be passed in most API calls. The point of custom data is to add any additional metadata you need to store for resources, that you can’t store using predefined fields. There is a limit of 10kb for custom data objects.

As an example, let’s say you wanted to create a Payment resource, and wanted to store the payer’s username on your platform in the WePayPayment API object. You could add a key value pair to custom data, like so:

"custom_data": {
    "merchant_username": "merchant1"
}

And any time you retrieve or update this payment, the custom data will be stored and returned. Custom data is a JSON object, and keys and values must be strings. The API will not overwrite data, but continue to append new keys and values. If you’d like to remove keys and values, you can assign existing keys to null, or, to remove the keys, set custom_data to null, and re-add data. Do not send personally identifiable information (PII) through custom data.

Custom Data is available on all API resources, except:

  • Transaction records
  • rBits
  • Orders
  • Items

Now that you have the basics down, start the Clear or Link Basic Integration. Questions? Need help? Visit our support page!