(Master) ShopeePay Acquiring Service API (Internal Only. Please Export PDF For Partner)
(Master) ShopeePay Acquiring Service API (Internal Only. Please Export PDF For Partner)
1. Introduction 4
1.1 About this Document 4
1.2 Intended Audience 4
1.3 Version Control 4
2. Definitions 5
2.1 Payment Methods 5
2.2 Term Definitions 6
3. System Requirements 7
3.1 Prerequisite 7
3.2 API Rules 8
3.2.1 Protocol Rules 8
3.2.2 Parameter Specifications 9
3.2.2.1 Request Header 9
3.2.2.2 Response Body 9
3.2.2.3 Transaction Amount 9
3.2.3 Security Specification 11
3.2.3.1 Signature 11
3.2.3.2 Signature Verification 12
3.2.4 Access Nodes 13
5. Common APIs 97
5.1 Notify Transaction Status 97
5.2 Check Transaction Status API 100
5.3 Create Refund API [New] 105
5.4 Get Transactions API 109
5.5 Set Merchant API 110
5.6 Set store API 114
Appendix 118
Appendix 1A - Transaction Types 118
Appendix 1B - Payment Status 121
Appendix 1C - Transaction Status 122
Appendix 1D - Promotion Types 123
Appendix 2 - Point of Initiation 124
Appendix 3 - Merchant Category Codes (MCC) 125
Appendix 4 - National Identity Types 125
Appendix 5 - Error Codes 128
Version Control 129
It describes the APIs between ShopeePay and any client system which intends to offer
ShopeePay as a payment option in their system, such as merchant aggregator systems, point-
of-sale (POS) systems, Independent Software Vendor (ISV) system and online commerce
platforms.
The user will perform a one-time authentication and authorization to successfully link
ShopeePay on the external platform. An access token will be issued by ShopeePay and used by
the external platform for a fast and seamless payment experience in the future.
The client generates a physical ticket that will be passed to the user, which contains information
of the service provided by the client. The user will perform a one-time authorization to link their
ShopeePay account to the ticket via scanning the ticket. Clients will be able to make a one-time
ticket payment charge to the user’s ShopeePay account for the linked ticket within a certain
period after ticket linking.
Term Definition
Merchant A business entity that can have one or more stores operating under it
User ID For on-us payments, the user_id_hash is an alphanumeric string of the hashed
Hash ShopeePay userid making payment.
For off-us payments (ID only), the user_id_hash is a numeric string of the
primary account number of the user making payment.
Signature Signature is created based on shared secret key and algorithm, used by
ShopeePay and client to verify each other’s identity in every API request. The
signature algorithm is created and provided by ShopeePay. The common
signature modes used are HMAC, SHA-256, Base64
Secret Key A secret key that is shared between ShopeePay Server and the Client. This key
is used to generate the Signature to authenticate the client.
[ Note ] Never hard code the secret key in a frontend application. All API calls
should only be made from the Client’s servers.
3.1 Prerequisite
Once commercial agreement between ShopeePay and client is finalised, each merchant will be
assigned the following for integration testing purposes
Name Description
Client ID Unique identifier to identify the caller of each request, to be added to the
request header of each API call.
Secret Key Only ShopeePay and the Client should know the shared secret. Secret
Key will be shared offline.
Component Format/Method
Name Description
Client system’s logic should not assume that the order of arrangement of response parameters
or the total number of parameters returned will remain constant throughout time.
● Integer format
Example:
● For currencies like IDR and VND, that do not have denomination in cents, the smallest
amount will be 100, which represents 1 IDR (Rp 1) and 1 VND (₫ 1).
There will not be a default currency. The current supported currency will be:
3.2.3.1 Signature
A signature should be generated from the request body to authenticate the request. A secret
key is needed to sign the request body. Please request from our technical team if you do not
have one.
The signature is a hash-based message authentication code (HMAC) using the SHA256
cryptographic function and the aforementioned secret key, operated on the request JSON. Code
implementation using some common programming languages is listed below for your
reference. You could check the implementation in more programming languages at this public
docs.
Golang import (
"crypto/hmac"
"crypto/sha256"
"encoding/base64"
)
The signature should be added in the HTTP header in the following format:
X-Airpay-ClientId: <clientid>
X-Airpay-Req-H: <request_signature>
Signature Example
Secret: pz148x0gXyPCLHxnlhEydNLg55jni91i
5f5532bf23018674788770f43743522dff1af5782243fab06b1e8677a7391d4c
3. Encode to Base64
X1UyvyMBhnR4h3D0N0NSLf8a9XgiQ/qwax6Gd6c5HUw=
Upon receiving the API response, the Client should verify the signature of the response in the
following way:
1. Use the shared secret to sign the response body to obtain the response signature.
2. Compare the generated signature to the signature in the header of the API response.
ShopeePay access nodes are country specific, each country will have their own API domains to
be called.
Indonesia ID co.id
Malaysia MY com.my
Philippines PH com.ph
Singapore SG sg
Thailand TH co.th
Vietnam VN vn
Environment Domain
sandbox api.uat.wallet.airpay.<region>
live api.wallet.airpay.<region>
2) User clicks on “Scan” icon on ShopeePay homepage and scan the QR code, as shown in
figure 4.1.2
3) User confirms the payment amounts and apply any merchant voucher if applicable, as
shown in figure 4.1.3
4) The user enter PIN to proceed with the payment, as shown in figure 4.1.4
See screenshots on the following page for the front-end user flow on ShopeePay.
1) The client backend generates a QR code by calling ShopeePay system (Create merchant-
presented dynamic QR API) and displays it to the user to be scanned
2) The user scan the QR code, checks payment amount and input PIN to proceed with the
payment
3) ShopeePay system returns the transaction result to user and the user is redirected to
payment successful page.
4) ShopeePay also sends asynchronous message via callback URL (Notify transaction
status) to inform client backend regarding payment result.
5) If no response from ShopeePay Server, Client can check transaction status by calling
ShopeePay Check Transaction Status API
(1) 5 seconds
(2) 10 seconds
(3) 15 seconds
(4) 20 seconds
(5) 25 seconds
.
.
.
7) After 100 seconds of retry with no response from ShopeePay, client can consider
payment transaction to have timed out.
8) If buyer can show evidence of payment success on their payment app, merchant can
choose to consider payment as successful and wait for reconciliation process on T+1 to
settle discrepancies if any.
Use this API to generate a dynamic QR code containing the payment amount and unique
payment reference ID.
● URL: "/v3/merchant-host/qr/create"
Request Parameters
Response Parameters
Sample Request
Use this API to invalidate the payment reference in a QR code if the order in Client system is
closed/cancelled. Once QR is invalidated successfully, the QR code containing the payment
reference ID can no longer be used to make payment.
● URL: "/v3/merchant-host/qr/invalidate"
Request Parameters
Response Parameters
Response Request
Response Response
1) User have to click on “Pay” button as the entry point for CPM option in QR Offline
Payments, as shown in figure 4.2.1.
2) User is prompted to enter ShopeePay pin before showing the QR/barcode, as shown in
figure 4.2.2.
3) User QR is shown on ShopeePay, as shown in figure 4.2.3. Merchant scans user QR and
submits payment requests to ShopeePay system. User can choose to pay using
barcode, as shown in figure 4.2.4.
5) Payment Code expires when client does not scan User’s QR/barcode within the 1 minute
expiry time. User will have to click renew code and generate another Payment Code for
payment, as shown in figure 4.2.6.
See screenshots on the following page for the front-end user flow on ShopeePay.
Figure 4.2.4 Switch to Figure 4.2.5 User redirected Figure 4.2.6 Payment Code
barcode payment method to payment success page expired
1) User clicks on the “Pay” button on ShopeePay homepage to generate QR/barcode valid
for 1 minute
3) Client calls Create CPM Payment API on ShopeePay Server with the transaction value
4) ShopeePay system returns the transaction result to client, and informs user of the
successful payment on ShopeePay App.
5) If there’s no response from ShopeePay Server before request timeout (time out duration
is determined by Client), Client can check transaction status by calling Check
Transaction Status API
a) Success - Payment process stops and user walks out of the store with purchase
● 5 seconds
● 10 seconds
● 15 seconds
● 20 seconds
● 100 seconds
7) After 100 seconds, payment transaction will timeout (ShopeePay will issue a timeout on
that request) and the merchant should refund the original payment transaction before
attempting payment creation again.
b) Fail - transaction can be found but it does not meet the requirements for refund,
merchant can try again at a later time.
9) If the user making the payment can show evidence of payment success on their
payment app, merchant can choose to consider payment as successful and wait for
reconciliation process on T+1 to settle discrepancies if any.
Use this API to initiate a payment request after scanning a user’s CPM QR.
● URL: "/v3/merchant-host/transaction/payment/create"
Request Parameters
Sample Request
2) User clicks on the payment confirmation button in the Client’s application to confirm
they are paying with ShopeePay, as shown in Figure 4.3.2.
a) If not, notify or redirect the user to install Shopee App first before completing
payment.
b) If yes, redirect the user to the ShopeePay payment amount page on Shopee app,
as shown in Figure 4.3.3.
4) Upon selecting payment options/vouchers in ShopeePay (if any), User enters their
ShopeePay PIN to proceed with the payment, as shown in Figure 4.3.4.
5) If the payment is successful, User sees the successful payment screen, as shown in
Figure 4.3.5.
6) User jump backs to the original Client’s application and view their order status, as shown
in Figure 4.3.6. External application can then release the order to the user after receiving
notification of a successful payment from ShopeePay system.
See screenshots on the following page for the front-end user flow on ShopeePay.
Figure 4.3.4 User is prompted Figure 4.3.5 User redirected Figure 4.3.6 Client’s app
to enter pin to payment success page success page
1) After User creates an order on the Client’s app and confirms to pay by ShopeePay,
Client’s app calls Order Create API to get the redirect URLs to ShopeePay.
2) User clicks on the redirect URL to jump to ShopeePay payment screen. Before the user
is redirected to ShopeePay, the Client’s app should check if the user’s device has
Shopee App installed.
a) If the Shopee App is not installed, it is recommended that the Client app redirects
the user to install the shopee app using the redirect_url_http link returned in Order
Create API, for an optimal user experience.
3) ShopeePay app displays order details using payment identifier in redirect URL.
4) User checks the payment amount and inputs Shopeepay PIN to complete the payment.
5) ShopeePay system returns the transaction result and the user is redirected to payment
successful page. From the payment success page in ShopeePay, user can jump back to
the Client’s app using the return_url to view their order status.
[ Note ] Never use the redirect to return_url as an indication of payment success. Client
should only rely on server request/response to check the final status of payment.
6) ShopeePay sends the transaction status update via callback URL (Notify transaction
status) to inform the Client about the payment result.
7) Client can also call Check Transaction Status API to check the payment status.
a) Success - Payment process stops and user walks out of the store with purchase
(1) 5 seconds
(2) 10 seconds
.
.
.
(5) 30 seconds
9) After 30 seconds of retry with no response from ShopeePay, client can consider
payment transaction to have timed out. Differences can be settled during the T+1
reconciliation process with ShopeePay.
● URL: "/v3/merchant-host/order/create"
Request Parameters
Response Parameters
Sample link:
shopeeid://main?apprl=%2Frn%2FTRANSFER_PAGE
%3Fnavigate_url%3Dhttps%253A%252F
%252Fwallet.airpay.co.id%252Fwallet%252Fpay
%253Ftoken%253D{paymentToken}
Sample link:
https://wallet.airpay.co.id/universal-link/wallet/pay?
deep_and_deferred=1&token=${paymentToken}
Sample Request
[ Note ] In Thailand and Vietnam, when ShopeePay redirects user back to the return_url provided
in the Client’s API request, the following parameters may be appended in the return_url. Client
may utilize such information to display some preliminary results to users on front end.
Example: https://www.google.com/?
amount=2000&client_id=11000193&reference_id=Test_returnURL_03&result_code=100&signatu
re=hw8FvuV1oVLTNuII7Xafawfqv1BGZsceeTpzo%3D&transaction_sn=1007011238
Enumerations:
- 100: payment success
- 201: payment cancelled but the
redirection_url is still usable
- 202: payment failed
- 203: payment still in processing
- 204: payment expired
Use this API to invalidate the existing order payment reference id for the pending order in the
Client system if it is closed/cancelled. Once the order payment reference id is invalidated
successfully, the corresponding “redirect_url_app” and “redirect_url_http” can no longer be used
to make payment.
● URL: "/v3/merchant-host/order/invalidate"
Request Parameters
Response Parameters
Sample Request
1) User links their ShopeePay account to the Client’s application during checkout/purchase
on the Client’s application, as shown in Figure 4.4.1.
2) If User has not logged in yet, User will be redirected to login page, as shown in Figure
4.4.2. (Note: Login page UI in Thailand and Vietnam are slightly different)
3) After login, User is redirected to the ShopeePay Agreement Page to authorise the linking,
as shown in Figure 4.4.3.
5) User sees the result of the account linking on the ShopeePay application and/or Client’s
application, as shown in Figure 4.4.5.
7) User can unlink ShopeePay via the Client’s platform or via the ShopeePay/Shopee App,
as shown in Figure 4.4.7 and Figure 4.4.8 respectively.
8) Once the ShopeePay account is unlinked, User is not able to access ShopeePay from the
Client’s platform anymore.
Note: if Client in Indonesia, Malaysia, Philippines or Singapore requires phone number match,
the linking flow will be slightly different: Agreement Page -> PIN Verification -> OTP Verification
See screenshots on the following page for the front-end user flow.
Figure 4.4.4 User enters PIN Figure 4.4.5 User sees the Figure 4.4.6 User receives a
to verify result of the account linking push notification upon
successful linking
1) User chooses to pay with the linked ShopeePay account on the Client’s platform, as
shown in Figure 4.4.9.
2) User may be prompted with ShopeePay PIN verification again, as shown in Figure 4.4.10.
3) If the payment is successful, User will see a payment success page on the Client’s
platform, as shown in Figure 4.4.11.
Note: the PIN verification process during Direct Payment is currently not applicable to Thailand
and Vietnam.
See screenshots on the following page for the front-end user flow.
1) User pays with the linked ShopeePay account on the Client’s platform, as shown in
Figure 4.4.12.
2) User may be prompted with ShopeePay PIN verification again, as shown in Figure 4.4.13.
4) If capture (actual payment) is successful after auth, User will receive another push
notification in ShopeePay/Shopee App, as shown in Figure 4.4.15.
Note: Auth and Capture flow is temporarily not available in Thailand and Vietnam.
See screenshots on the following page for the front-end user flow.
Figure 4.4.12 User pays with Figure 4.4.13 User may be Figure 4.4.14 Push
linked ShopeePay prompted with PIN re- notification for successful
authentication fund reservation
1) After User chooses to link their ShopeePay account, Client calls the Account Link API to
kick start the linking process.
a) If the user’s phone number is passed in the request, ShopeePay checks internally
if the phone number belongs to a valid ShopeePay user and returns a web URL
for Client to redirect the user to.
2) Client redirects User to the ShopeePay agreement page. User reads and consents to the
permissions required by the Client, and completes both ShopeePay PIN and OTP
verification. After successful verification, User is redirected to the Client’s page as
indicated in the ’return_url’ in the Account Link API request along with an auth code.
4) If User chooses to unlink ShopeePay, Client calls the Account Unlink API to invalidate the
ShopeePay access token.
a) If Client wants to display the redeemable Shopee coins value to the User:
i) Client can call Get Redeemable Coin Value API to get a maximum coin
redemption percentage allowed; OR
b) If Client does not need to display the redeemable Shopee coins value to the User:
i) Client can call Direct Payment API to initiate a direct charge. A redirect url
to the ShopeePay PIN verification page may be returned if this verification
2) ShopeePay sends the transaction status update via callback URL (Notify transaction
status) to inform the Client about the payment result.
3) Client can also call Check Transaction Status API to check the payment status.
Auth capture flow is useful for merchants (e.g. Ride hailing apps) that want to reserve a user's
fund first and only deduct either a full or partial amount later.
1) User expresses intent to make a purchase (e.g. attempts to book a taxi via a ride hailing
app)
a) Client calls Create Auth API to reserve the estimated amount to be charged. After
successful fund reservation, client can inform the user that they can successfully
proceed to the next step (e.g. client app informs the user that their booking for
the taxi is successful.
b) Once the user has received the product/service (e.g. after a taxi ride is complete),
client calls Capture API to collect the final payment amount (e.g.deduct the final
2) If user exits the purchase process (e.g. cancels the taxi booking before the ride begins),
Client can call Reverse Auth API to release the funds reserved during Auth.
3) Similar to the direct payment flow, ShopeePay sends the transaction status update via
callback URL (Notify transaction status) to inform the client about the payment result.
4) Client can also call Check Transaction Status API to check the payment status.
Note: Auth and Capture flow is temporarily not available in Thailand and Vietnam.
Use this API to kick start the account linking process of a ShopeePay account to your platform
● URL: "/v3/merchant-host/account/link"
Request Parameters
Note:
- Client is strongly encouraged to
pass in this value for better
tracking and identification
purposes.
- This field is currently only
available in TH, VN.
Accepted values:
● “app”
● “pc”
● “mweb” (mobile web)
● “qr” (for scan QR linking)
Response Parameters
Sample Request
Sample Response
Use this API to get a ShopeePay access token using auth code returned in the account linking
step.
● URL: "/v3/merchant-host/access-token/get"
Request Parameters
Sample Link:
www.isv-integrator.com/payment?
authCode=AQhTc89wVeKkDUX91jCVAg
Yf6swAydVH&result=100&ticket=bvhmj3
lq1clggb75u9n0pkndu
some_app://{redirect_page}?
authCode=AQhTc89wVeKkDUX91jCVAg
Yf6swAydVH&result=100
Result codes
100 - User authentication success
201 - User cancelled linking
202 - Account linking failed
Sample Response
Use this API to unlink a ShopeePay account from a User’s account on your platform.
● URL: "/v3/merchant-host/account/unlink"
Request Parameters
Response Parameters
Sample Request
Sample Response
Use this API to get a user’s ShopeePay account information for display purposes.
● URL: "/v3/merchant-host/user-info/get"
Request Parameters
Either linking_reference_id or
access_token should be provided in the
request.
Either linking_reference_id or
access_token should be provided in the
request.
Response Parameters
Sample Request
Sample Response
Use this API to get the user's maximum redeemable coin amount in percentage or in absolute
amount.
● URL: "/v3/merchant-host/coin/potential-redemption"
Note: This API is temporarily unavailable for use in Thailand and Vietnam.
Request Parameters
Response Parameters
Sample Response
● URL: "/v3/merchant-host/transaction/payment/direct"
Request Parameters
Response Parameters
Sample Response 2 (when ShopeePay PIN verification is required, not applicable to TH/VN)
Use this API to create an auth transaction to reserve funds for subsequent capture.
● URL: "/v3/merchant-host/transaction/auth/create"
Note: This API is temporarily unavailable for use in Thailand and Vietnam.
Request Parameters
redirect_url string The URL for the Client’'s frontend to redirect to for
PIN verification, valid for 30 mins. Only applicable if
PIN verification is needed.
Sample Response
Use this API to reverse funds reserved previously using an auth request.
● URL: "/v3/merchant-host/transaction/auth/reverse"
Note: This API is temporarily unavailable for use in Thailand and Vietnam.
Request Parameters
Response Parameters
Sample Response
Use this API to create a full or partial capture transaction using funds reserved from the
corresponding auth transaction. Capture must be requested before the auth transaction
expires. Only one partial capture will be accepted for each auth transaction..
● URL: "/v3/merchant-host/transaction/auth/capture"
Request Parameters
Response Parameters
Sample Response
1) User obtains the physical ticket (containing QR or Barcode) from the client.
2) User clicks on “Scan” icon on Shopee/ShopeePay homepage and scan the QR code, as
3) If the ticket is valid, User can verify the ticket details and select vouchers and coins
4) User inputs ShopeePay PIN to confirm the ticket linking, as shown in figure 4.5.4
5) If the linking is successful, User will see the successful linking result, as shown in figure
4.5.5
6) User passes the ticket to the cashier when requested, and the ticket will be charged by
7) If payment is successful, User will be able to check their transaction history and see the
Figure 4.5.4 PIN Verification Figure 4.5.5 Successful Figure 4.5.6 Successful
for the User after confirming linking page deduction of ticket payment.
ticket details.
2) User will scan the ticket generated by Client, and ShopeePay will call Client's endpoint to
validate the Ticket.
3) User will be redirected to the ticket detail page and configure the ticket linking.
4) After User confirms their configurations, ShopeePay will require User to verify
ShopeePay PIN first and call Client to confirm this linking action
5) After Client responds ‘Success’ to ShopeePay, Shopeepay will redirect to the linking
successful page
6) The cashier will request for the physical ticket from the User to process the payment,
and the Client will call the ticket charge API when the cashier receives the ticket to do
payment deduction from user’s ShopeePay account
7) If there’s no response from ShopeePay Server before request timeout (time out duration
is determined by Client), Client can check transaction status by calling Check
Transaction Status API
● 5 seconds
● 10 seconds
● 15 seconds
● 20 seconds
9) After 100 seconds, payment transaction will timeout (ShopeePay will issue a timeout on
that request) and the merchant should refund the original payment transaction before
attempting payment creation again.
10) Calling Create Refund [New] API will return 2 status types:
b) Fail - transaction can be found but it does not meet the requirements for refund,
merchant can try again at a later time.
Use this API to initiate a payment request after scanning the User's ticket.
● URL: "/v3/merchant-host/transaction/ticket/charge”
Request Parameters
Response Parameters
Sample Response
1) User pays cash to the merchant. The Cash amount paid to the merchant includes the
topup amount and transaction fees charged by the merchant for the transaction.
2) Merchant checks that the cash amount received from User is correct.
4) User goes to ShopeePay Homepage to click on either “Scan” or “Top Up” as shown in
Figure 4.6.2.
a) If User clicks on “Top Up” icon on ShopeePay homepage, they can select the top
up via QR scan option, as shown in Figure 4.6.3.
5) User checks all details are correct, and presses the “Top Up” button to complete the
topup, as shown in figure 4.6.5.
6) If the cash in is successful, User sees the successful top up screen, as shown in Figure
4.6.6.
See screenshots below for the front-end user flow on ShopeePay for Cash In
1) The client backend generates a QR code by calling ShopeePay system (Generate Cash In
QR Code API) and displays it to the user to be scanned
2) The user scan the QR code, checks Cash In (Top Up) amount and transaction fee to
proceed with the Cash In
3) ShopeePay system returns the Cash In (Top Up) result to the user and the user is
redirected to the Cash In (Top Up) successful page.
4) ShopeePay also sends asynchronous message via callback URL (Notify transaction
status) to inform client backend regarding payment result.
5) If no response from ShopeePay Server, Client can check transaction status by calling
ShopeePay Check Transaction Status API
6) After 100 seconds of retry with no response from ShopeePay, client can consider Cash
In (Top Up) transaction to have timed out.
4.6.2 API
Use this API to generate a dynamic QR code containing the top up amount and unique payment
reference ID.
● URL: "/v3/merchant-host/cash-in/qr/create”
Request Parameters
Response Parameters
Sample Request
Sample Response
Use this API to invalidate a Cash In QR Code generated previously by Client. Once QR is
invalidated successfully, the QR code containing the payment reference ID can no longer be
used to make Cash In transactions.
● URL: "/v3/merchant-host/cash-in/qr/invalidate”
Request Parameters
Response Parameters
Sample Response
Each callback request will contain a signature in the request header. This signature is generated
using the ShopeePay-issued secret key, assigned to the Client receiving the callback request.
The Client should use this signature to verify the authenticity of the callback content.
Multiple repeated notifications might be sent to the Client and Client shall be able to handle the
repeated notifications with same contents properly.
[ Note ] It is essential for the Client to validate that payment amount and payment_reference_id
matches the original /qr/create request before considering the payment as successful.
Common Fields
For ID, MY, PH, SG: Additional Fields For Transactions that are not part of Account Linking
APIs
For ID, MY, PH, SG: Additional Fields For Transactions that are part of Account Linking APIs
Callbacks for transactions related to Account Linking (i.e. Payment Authorization, Payment
Capture, Authorization Reversal, Direct Payment) will contain the following fields.
Response Parameters
Note: in Thailand and Vietnam, if Client does not respond with code = 0, ShopeePay will resend
notifications up to 2 times.
Sample Callback For Transactions that are part of Account Linking APIs
● URL: "/v3/merchant-host/transaction/check"
1) Success - payment process stops and Client can mark this transaction as success.
2) Not found - retry the payment process from the start
3) No response - continue retrying
a) Retry should be done at an incremental time range, at our recommended retry
timing at the following time marks:
i) 5 seconds
ii) 10 seconds
.
.
.
vi) 30 seconds
4) After 30 seconds of retry with no response from ShopeePay, Client can consider
payment transaction to have timed out. Differences can be settled during the T+1
reconciliation process with ShopeePay.
[ Note ] This API is an upgraded version of previous Check Payment Status API to support
transaction status inquiry for all transaction types including Auth, Capture and Auth Reversal.
Request Parameters
Response Parameters
Sample Request
Sample Response
● URL: "/v3/merchant-host/transaction/refund/create-new"
● Refund Types: Full refund only for SG; Partial refund supported for ID, MY, PH TH, VN.
Request Parameters
Response Parameters
Sample Response
The maximum number of transactions returned for each API request is 5000. API requests
should be made multiple times in succession until the response body is empty, indicating that
all transactions within the time range have been returned.
For every new API request made within the specified time range, the request should indicate a
last_reference_id value, which is the reference_id of the last transaction returned in the response
of a previous API request.
The transactions will be returned in Descending order by update time (i.e. the latest transaction
will be returned first).
● URL: “/v3/merchant-host/transaction/list”
Note: This API is temporarily unavailable for use in Thailand and Vietnam.
Request parameters
Response Parameters
● amount int64 Amount used for the payment, inflated by a factor of 100
● URL: “/v3/merchant-host/merchant/set”
Note: This API is only available in Philippine and Malaysia based on ShopeePay operational
requirements.
Periodic Update: It is highly recommended for Clients to sync the latest Store information in
their system to ShopeePay, to ensure all users can enjoy a smooth payment experience at newly
added/updated Stores.
The following diagram represents the structure of Merchants and Stores in ShopeePay that
integration partners should adhere to during onboarding and sending payment requests.
Payments are only accepted on the Store level.
Request parameters
Response Parameters
extinfo object
● business_tax_id string
Clients can update information of previously added merchants via the Set Merchant API, using
“merchant_ext_id” as the identifier for each merchant.
Fields that are not filled in in the Set Merchant API during updating will not be updated.
Fields that are mandatory during merchant onboarding cannot be updated to empty values.
● URL: “/v3/merchant-host/store/set”
Note: This API is only available in Philippine and Malaysia based on ShopeePay operational
requirements.
Request parameters
Compulsory for ID
Response parameters
extinfo object
Clients can update information of previously added merchants via the Set Store API, using
“merchant_ext_id” and “store_ext_id as the identifier for each merchant.
Fields that are mandatory during store creation cannot be updated to empty values.
Payment 13 Y
Refund 15 Y
Adjustment (Add) 32 Y
Adjustment (Deduct) 33 Y
Cash In 36 Y
Cash Out 37 Y
*[Note] The following Transaction Types have different values in Thailand and Vietnam
- Direct Payment: 13
- Direct Payment Refund: 15
Payment successful 1
Payment refunded 3
Payment processing 5
Payment failed 6
Transaction initial 1
Transaction processing 2
Transaction successful 3
Transaction failed 4
Transaction expired 6
Coins 1
Cashback 2
Discount 3
Bakeries 5462
For other merchant category codes, clients may choose to take reference from the merchant
standards manual by Visa
ID 1 KTP
ID 2 KITAS
MY 1 IC
MY 2 Passport
SG 1 NRIC
SG 2 FIN
PH 1 Passport
PH 2 Driver’s License
PH 8 TIN ID
PH 14 Police Clearance
PH 16 Senior Citizen ID
PH 18 TIN Card
PH 19 OFW ID Card
PH 20 PWD ID
PH 21 PhilSys ID
Value Description
0 Success
2 Permission denied
6 The user making the payment has not completed wallet activation
7 Expired
11 Duplicate request/transaction
42 Insufficient balance
309 MDR fee don't have enough balance where merchant doesn't have enough
balance to refund a transaction
601 Request to refund a payment transaction does not meet rules. This error is
also returned during refund block periods, set at 11.55pm to 3am by default.
This timing is subject to changing during campaign periods or system
maintenance.
V1.56.1 17.11.2020 G.K. 1- Added Cash In (Top Up) flows and APIs
2- Added New Transaction Type
V1.56.2 08.1.2021 W.T, 1- Added new error code mapping - 5, for payment
Y.C processing, check callback and check status API
for updated status
2- Added new error code 1001 and 1002, to
handle access control and system maintenance
use case.
V1.56.4 26.1.2021 S.F. 1- Updated default withdrawal option for Set Store
API
V1.56.5 26.2.2021 G.Z. 1 - Updated valid void period from 365 days to
within the create date of the original payment
V1.58 13.4.2021 Y.X. 1 - Remove access scope field in Get User Info
API response
2 - Remove Appendix 6 - Access Scope
3 - Update `payment_reference_id`,
`auth_reference_id`, `reverse_auth_reference_id`
and `capture_reference_id` description in Account
Linking Direct Payment, Create Auth, Reverse
Auth, Capture APIs
V1.59 19.4.2021 G.Z. 1 - Deprecate Void API. Refund API provides the
same functionality to fulfil the refund needs of
ISVs and merchants
V1.62 24.5.2021 G.Z., P.L. 1 - Add kyc_passed value in Get User Info API
2 - Indicate the partial refund capability of Create
Refund API [New] in Thailand and Vietnam
3 - Indicate a temporarily unavailable API in
Thailand and Vietnam: Get Transactions AP
4 - Add co_funding in the responses of following
APIs: Create Refund API [New], Check Transaction
Status API [New], Create CPM Payment and in the
request of Notify Transaction Status API.
Note: this field will only be available for Thailand
and Vietnam.
V1.63 19.7.2021 P.L. 1 - Add new error code 150 (active linking count
threshold reached) for Account Link API
2 - Indicate a temporarily unavailable field
(user_id_hash) in Thailand and Vietnam
3 - Add “platform_type” field in request
parameters for Create Order API in Thailand and
Vietnam and indicate that “point_of_initiation”
field’ in Create Order API is for ID, MY, PH, SG only
4 - Indicate non-applicable result codes in
Account Link API in Thailand and Vietnam
5 - Indicate a temporarily unavailable response
field (redirect_url_app) in Thailand and Vietnam
for Create Order API
6 - Add Transaction Type 1004 for Capture Refund
and 1005 for Direct Payment Refund
7 - Indicate a non-applicable flow: Cash in and
non-applicable APIs: Generate Cash In QR Code
API and Cash In QR Invalidate API in Thailand and
Vietnam
8 - Add expiry_time field in the following APIs:
Create Dynamic QR, Create CPM Payment, and
Create Order. This field is only applicable in
Thailand and Vietnam.
9 - Update Check Payment Status API to be Check
V1.64 23.7.2021 G.Z., P.L., 1 - Add eligible National ID Type value = 21, for PH
M.E. PhilSys ID
2 - Add error code 152 for failure to unlink account
linking due to ongoing auth transactions
3 - Add transaction_sn in the response
parameters for Direct Payment and Capture API
4 - Remove Check Payment Status and Create
Refund API from API docs as new merchants
shall always call Check Transaction Status and
Create Refund [New] API instead
5 - Add user_id_hash in the response of Get
Access Token API
6 - Add Ticket Linking in Payment method
Definition
7 - Add new Ticket Linking Flow
8 - Add new Point of Initiation for Cross Border,
Disbursement and Ticket Linking
9 - Indicate that the PIN verification process in
Direct Payment Flow is currently not applicable to
Thailand and Vietnam.
10 - Add response parameters for Notify
Transaction Status and retrying logic
11 - Indicate error 50 for wrong request format
12 - Indicate the availability of user_id_hash in all
API response for Thailand and Vietnam
13 - Add additional_info in the request parameters
of Direct Payment
14 - Add parameters appending mechanisms
when visiting return_url in App-to-app redirection
payment flow in Thailand and Vietnam
15 - Remove mcc and terminal_ ip request
parameters from CPM Create Payment API
16 - Remove point_of_initiation request
parameters from Create Order API
V1.65(WIP) 12.10.2021 P.L., G.Z., 1 - Remove the ‘Full Refund Only’ remark for
M.E. Indonesia, Malaysia, and Philippines. Partial
Refund is now available in all regions except for
Singapore.