As a Developer of MobilePay API's , you'll be working with credentials issued to you from MobilePay, as well as tokens.
- Client ID
- Your Client ID is one piece of information used to identify your application and frequently appears in OAuth negotiation URLs and other contexts. Your Client ID can be shared freely in code and email and cannot be used alone to act on your application's behalf.
- Client Secret
- If your secret leaks, no use crying over it like spilled milk. Regenerate your secret using the "reset" button.
- Do not hard-code any tokens into your code, instead use a database to store tokens.
- Delete the token immediately from production and back-ups, if you no longer have the need for the merchant token
- Validate TLS certificate chains: the client must validate the TLS certificate chain when making requests to protected resources. Failing to do so may enable DNS hijacking attacks to steal the token and gain unintended access
- Always use TLS (https): Clients must use TLS (https) or equivalent transport security when making requests with bearer tokens.
- Don't store bearer tokens in cookies: implementations that do store bearer tokens in cookies MUST take precautions against cross-site request forgery.
- Use a OpenID Connect library that has built-in token management
- Ensure that there is no way of exposing the merchant token (or the functionality of that token) to another user by accident.
- Be aware of the fact that access can be revoked at any time. Once consent is revoked, the integrator will not be able to use the access token or the refresh token. You will need to get consent again.
- Protect all types of tokens and secrets. Keep them secret. Keep them safe. It is your responsibility to keep them secret
- Adhere to the principle of least privilege. Applications should never request more than the minimum permissions needed to function properly.
- We recommend that after you complete local development, remove localhost and related domains from your configuration list.
- Do not send us your tokens.
- The tokens should never be exposed.
- Focus on having logic, that ensures that when you use
access token, then you also check if it is expired. The logic should tell you, for how long the access token is valid, so that you can know, when it is time to refresh the
access token, without making a call to MobilePay service and receiving 401. When it is expired, then you can use
refresh_tokento get a new valid refresh token.
refresh_tokenexpires within one year, so there is no need constantly call with it. It will create extra noise and traffic in our logs, and we at MobilePay want to avoid that.
- Refresh Tokens are subject to strict storage requirements to ensure that they are not leaked.
- Although Access Tokens can be renewed at any time using Refresh Tokens, they should be renewed when old ones have expired, or when getting access to a new resource for the first time.
You should only ask for a new token if the
Please avoid hitting the rate limits in that will throttle the amount of requests to this endpoint that can be executed using the same token from the same IP.
refresh_token must never be exposed. If you have any suspicion that they might be, you should contact us at email@example.com or the merchant in question, so the token can be revoked.
- Application has to be created
x-ibm-client-secretis required in the Authorization header
x-ibm-client-idis required in the Authorization header
access_tokenis required in the Authorization header
x-ibm-client-secret are generated after the application is created on the My apps page. The
x-ibm-client-secret can be found when clicking the app icon after the app is created. When making requests, the
access_token are sent in a header of each request. Note that both,
x-ibm-client-secret are always sent, in every single request that is made towards the API.