Cheatsheet-BestPractices-RazerMS_API
Objective
This is a cheatsheet for those developers who is frustrated by the lengthy official docs and having a hard time on deciding which option is the best approach to fit their integration requirements. This README.md file will be updated from time to time when we discovered new pain point faced by developers during the integration process. We welcome every suggestion or enquiry from developers in the form of posting new issue to this repository.
Tips #1. Various integration method provided by RazerMS
RazerMS provides few of the integration methods to suit every business needs.
i. Hosted Payment Page
A hosted solution where customer will be redirected from merchant site to RazerMS hosted page, channel selection will be done on this page before being redirected to each online banking / ewallet page to proceed with the payment authorization or OTP. After that a success / failure page will be displayed to customer before being redirected back to merchant site.
ii. Seamless Integration
Channel selection will be done in the merchant site which require more integration effort from the developers compared to Hosted Payment Page. For card channel the card number will still be input through RazerMS page hence no PCI compliance is required from merchant.
iii. Inpage Checkout
Similar to seamless integration but only support card channel, and the difference compared to seamless integration is the card number input page will be hosted via iFrame on merchant site instead of a popup window.
iv. Mobile XDK
Best for mobile in-app purchase.
v. Direct Server Integration
No UI will be provided by RazerMS, channel selection and card number input will all be done on merchant site, hence require merchant to be PCI compliant.
vi. Recurring API
No UI will be provided by RazerMS, but it supports recurring payment by any amount at any time.
Comparison Chart
Tips #2. The 3 endpoints to update payment status on merchant site
When a payment is done by customer, how do we update the transaction status to the merchant? The 3 endpoints, i.e. Return URL, Notification URL, Callback URL serves as a mechanism to update merchant transaction status.
i. Return URL
Realtime web browser or frontend redirection endpoint for hosted page, seamless integration, and shopping cart module. Impact user's UI/UX or journey in the whole payment process.
ii. Notification URL
Realtime server-to-server or backend endpoint for all kind of integrations and payment channels. Will be triggerred once RazerMS received the payment status from respective online banking / ewallet channels.
iii. Callback URL
Defer update or callback endpoint on non-realtime payment such as Razer Cash.
Tips #3. To enable IPN to avoid missing the webhook
IPN (Instant Payment Notification) is a mechanism whereby if enabled, merchant will be required to ACK (acknowledge) on each of the received webhook, i.e. notification and callback URL. In case merchant failed to ACK, we will assume that the previous webhook has failed and we will retry sending the webhook with an interval of 15 minutes until a maximum of 4 retries to the merchant Callback URL endpoint.
Tips #4. Get channel subscribed by using Channel Status API
For those merchant who are using integration type such as Seamless or Direct Server where the channel selection is done on the merchant site, developers are advised to get the channel subscribed by using Channel Status API.
Tips #5. For requery the difference between Direct / Indirect Status Requery
Requery is the API used to check for each transaction status by using Transaction ID or Order ID. But we have 2 different types of requery, i.e. Direct Status Requery and Indirect Status Requery.
i. Direct Status Requery
RazerMS will forward the status enquiry by merchant to the respective online banking / ewallet channel, which help the merchant to get realtime transaction status as aligned with the payment channel itself.
ii. Indirect Status Requery
RazerMS will return the transaction status based on our own status within our system.
Tips #6. For void use Reversal API, for refund use Refund API
We have 2 types of Refund, i.e. Reversal and Full / Partial Refund
i. Reversal
RazerMS will forward the refund request by merchant to the respective online banking / ewallet channel, and proceed to void the transaction, but this is only allowed on the same day as the transaction itself.
ii. Full / Partial Refund
RazerMS will process the refund request by merchant ourselves and allow up to 180 days after the transaction date.
Tips #7. Guest Checkout to disable save card feature
RazerMS provides save card features by requiring customer's basic info like billing name, mobile number and email. With that being said, this feature is only eligible for a registered user of the merchant's website. But there are also some checkout where merchant does not hold the customer's basic contact info, which is also known as a guest checkout. To disable save card feature for a guest user, merchant can pass the parameter bill_name=guest&bill_email=&bill_mobile= (case insensitive) to our payment page.
