top of page
DEVELOPERS
Technical FAQs
Here are answers to some of the technical questions we get asked the most. If you can’t find what you’re looking for, feel free to reach out directly to us.
The Basics
About Accounts
Key Integration Steps
Our API is an industry standard REST API, which returns JSON responses. We've streamlined the requests and responses to focus on just what you need to get the job done.
When your account with Qippay is onboarded, you will be provided with a client_secret to use with our API, and a beneficiary_id for each bank account number you need to receive payments into. Your calls to the API will all require the client_secret in the authentication header of the request.
Our API acts as a single connection point so your users can make payments from any of the banks we support.
You make the calls to Qippay's API, then we handle the communication with the bank they have selected and respond with the data you need to make the payment – you don't need any communication with the bank.
While you should always ensure that your client_secret and beneficiary_id are kept secure, our design and policies ensure that anyone in possession of these can only request users to make payments using your Merchant Name to your bank account. While it would be less than ideal, a rogue party cannot make payments to a different account using your credentials.
Yes it can! As a standard REST API, your app can make whatever calls are required, and the user’s mobile OS will handle any redirects to the Bank’s app, and back to your own app on completion.
The Basics
Our API is an industry standard REST API, which returns JSON responses. We've streamlined the requests and responses to focus on just what you need to get the job done.
When your account with Qippay is onboarded, you will be provided with a client_secret to use with our API, and a beneficiary_id for each bank account number you need to receive payments into. Your calls to the API will all require the client_secret in the authentication header of the request.
Our API acts as a single connection point so your users can make payments from any of the banks we support.
You make the calls to Qippay's API, then we handle the communication with the bank they have selected and respond with the data you need to make the payment – you don't need any communication with the bank.
While you should always ensure that your client_secret and beneficiary_id are kept secure, our design and policies ensure that anyone in possession of these can only request users to make payments using your Merchant Name to your bank account. While it would be less than ideal, a rogue party cannot make payments to a different account using your credentials.
Yes it can! As a standard REST API, your app can make whatever calls are required, and the user’s mobile OS will handle any redirects to the Bank’s app, and back to your own app on completion.
Key Integration Steps
We've got concise but thorough documentation that tells you everything you need to know. On top of this, we have a Postman collection, Swagger definitions, and a series of demonstration pages in multiple languages to help.
None at all! Qippay's API uses a standard REST interface with JSON responses, so you can use whatever toolsets your application requires – no additional libraries needed!
Yes we do, and you gain access to this once onboarded. Our UAT environment enables you to make all the same API calls as you will in production, to test your integrations before going live. As the banks we support typically require authentication via their live mobile apps, the UAT environment cannot enable testing with the real banks and instead provides fictional banks that represent a range of experiences matching what your users may encounter.
If you use Qip PayBy Hosted, you simply redirect the user to Qippay's hosted payment page and the user does bank selection, and everything thereafter form that page. If you use Qip PayBy Embedded, there can be different authorisation methods depending on the bank, but our API responses tell you what is required for the selected bank, so you can handle the response to guide your user.
There is some extra work, because you need to have the user provide their phone number and selected bank to initiate the payment. Once you have that information, depending on their bank and usage history the user may be redirected to their Bank's app or website (Hybrid Flow), or they might stay in your app while a separate approval request is sent to their Bank's app (Decoupled Flow). If they use a Decoupled Flow, your app will need to indicate that state, monitor the state of their approval and respond depending on if they approve, decline, or timeout.
Talk to our business & enterprise team
About Accounts
The bank account number along with the Merchant Name presented to users within their banking app, is set when you are onboarded, and is tied to your beneficiary_id. For your security, and that of your users, we do not enable the receiving bank account or Merchant Name to be changed via the API. If you require a change or an additional account, contact us and we will issue a new beneficiary_id reflecting the changes required.
There are many legitimate cases where the name an organisation trades under or is recognised by is different to the bank account name. Qippay robustly validates the identity of our clients and their operations, so we can ensure that the Merchant Name presented to users within their bank's app for approving a payment and on their statement matches the trading name that they recognise you by. As we have validated the Merchant Name as legitimate prior to issuing your beneficiary_id, your users will not encounter a Confirmation of Payee prompt and can have confidence they are paying the right party.
bottom of page