WePay

General questions about WePay

Difference between Stage and Production

The stage server and main production site are completely independent environments and have different databases. All the account ids, user ids, application ids, application tokens, etc. are different between stage and production environments. After you test your application on stage, you will need to create the application on production and use the production application ID and secret to connect to the production environment. Please note that the stage server does not process or move "real" money and, for example, allows the use of fake credit card numbers for testing.

How do I find my account_id?

The account_id is the globally unique ID of your WePay account. A WePay account is a place to hold money. Each user on WePay can open up as many WePay accounts as they want. To see which WePay accounts you have opened, go to the "Data" tab of your app dashboard. You can view all accounts you have created from here. You can also find all accounts opened for a user by making the /account/find call with the access_token associated with the user you want to find accounts for. This call will return an array of accounts, including any account IDs. To open an account for a user, you can make the /account/create call.

Problem with SSL certificate verification

The SSL certificate verification error reported by cURL library indicates that the cURL client does not have the correct trusted certificates configured:

Uncaught exception 'Exception' with message 'cURL error while making API call to WePay: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed'

Typically, this means that you have a very old (pre 7.18.0) version of cURL (see explanations in cURL docs). You should update your Curl package and check if it solves the problem by running the following command:

curl -G -v https://wepayapi.com/v2/account

If it works then webserver or php-fpm restart everything should work just fine. Otherwise,you can configure the trusted certificates manually as it is explained in this article.

What is an access_token?

The access_token is a long string of letters and numbers that you include in API calls to let us know what user you are making the API call and what permissions your app has for that user. Each access token is associated with:

  1. A user
  2. An API application
  3. The permissions that the Api Application has to do things for the user

So when you make an API call with an access token, the WePay API will be able to tell what App you are and what user you are making the call for just from the access token. If you want to make a call for user #1 you need to use the access_token you have for user #1, and if you want to make an API call for user #2, you should use the access token you have for user #2. For security reasons, the access token should NEVER be passed as a get or post argument. The access token should be passed in the 'authorization' HTTP request header. For more information on how to make an API call with an access_token see this tutorial: https://stage.wepay.com/developer/tutorial/api_call

What will the credit card statement look like?

For API payments, the credit card statement will always be of the form "WPY*account_name". Here the account_name is the name of the account created using the WePay API for a particular user. The character limit varies from bank to bank, but it usually is 14 to 20 characters. Please note that if a payment is not in captured state and is only authorized, most banks use the Merchant of Record's name on the credit card statement. In this case, the credit card statement will simply say "WEPAY, INC."'

How can an access_token get revoked?

Access_tokens can be revoked two ways:

  1. The user goes to their user settings on WePay and manually revokes the access_token.
  2. Your app requests a new access_token via the /oauth2/token call. Each time you make the /oauth2/token call, we revoke all access_tokens for that user that were previously issued to your app. You should only make the /oauth2/token call if the current access_token does not work.

Should I email you my access_token or client_secret? NO!

No! Please always keep any access_tokens you have secret. They should be handled with the same care that you handle a user's password. Email is not a secure communication medium, so you shouldn't include any non-public user information in any emails that you send to us.

What information CAN you send us? The following public information is fine, and will better help us solve any problems you have:

  • client_id
  • account_id
  • user_id
  • checkout_id
  • preapproval_id
  • withdrawal_id

How can I hide the fees from the payer during the checkout flow?

If you set the "fee_payer" parameter to "payee" on the /checkout/create and/or /preapproval/create calls, then the WePay fee will be charged to the recipient of the funds and will not be displayed to the payer.

Where can I view the current WePay API status?

The realtime WePay Status page displays the current status of our stage and production environments, scheduled maintenance, and upcoming releases.

What happened to the “settled” checkout state?

We are always improving our API, and to streamline the checkout, subscription_charge and withdrawal states, we are removing the “settled” state. This will also allow us to process chargebacks in very rare cases that occur outside our current settled state timelines. In these rare cases, a transaction can be reversed more than 180 days after the date it was recorded as “captured”.

If you would like to read the relevant MasterCard rules, please refer to section 1.7.3 of MasterCard's Chargeback Manual.

To support this change, we will be migrating all “settled” transactions to the “captured” state in the 02/19/14 release to our production environment. This is to allow for rare cases in which a merchant may receive a chargeback beyond 180 days (previously the “settled” date).

If you store the “settled” state in your database, you can migrate it to “captured”. Fortunately, this is not a breaking change, as your integration will not be affected, but we recommend this change for proper reporting. This change will also enable us to better support partner and merchant requests for refunds and transaction updates.