Precautions for using PAYJOA

The payment window call (IMP.request_pay) and post-payment processing differs for PC and mobile. In PC, the call is made using iframe and the callback function (the second argument of IMP.request_pay) is called after the payment process is completed. In mobile, the page is redirected (302) to the specified URL (m_redirect_url). At this time, the payment result (success/failure) is returned using the success parameter for PC and imp_success parameter for mobile. To summarize the flow:

• [PC] iframe → callback → result delivered in response.success returned via callback

  IMP.request_pay(
    {
      // Omitted
    },
    function (response) {
      const { success } = response; // payment successul or failed
      if (success) {
        // Success logic
      } else {
        // Failure logic
      }
    },
  );

• [Mobile] Redirect → redirct (302) to m_redirect_url → result delivered in imp_success query parameter

  /**
   * Sample 302 redirect URL redirected to after payment process is completed
   * when m_redirect_url is set to 'https://myservice.com/payments/complete'
   */
  "https://myservice.com/payments/complete?imp_success=true&imp_uid=imp1234567890&merchant_uid=mid_123467890";

imp_success and success are deprecated

Regardless you should not determine the success/failure of a payment based on either of these parameters. It only indicates the failure/success of payment at the time of the response from i’mport → merchant client, and its value can only be finalized when notification of the result is sent from PAYJOA → i’mport and then it is updated in the i’mport DB.

Since the payment result is sent asynchronously in [PAYJOA → i’mport → i’mport DB update] and [i’mport → merchant client], the imp_success or success parameter received by the merchant client can be false (failed) for a successful transaction if it has not been updated in the database yet.

Hence, only the i’mport order ID (imp_uid) and the merchant order ID (merchant_uid) of the result are accurate. You must send these values to the merchant server and use them to call the i’mport Get payment API (GET /payments/{imp_uid}) to accurately determine whether the payment is successful (status=paid) or failed (status=failed).

When paying with Hana card/NH Apps Cache (account transfer) in Safari, the message below (the session has expired and the connection with the card company has been terminated) is displayed and payment cannot be processed.

If you are experiencing this, make sure that the Prevent cross-site tracking and Block all cookies options are not checked in Safari Preferences as shown below, and then try again.

If you click the Next button after selecting BC Card in the credit card payment window, “Payment failed” alert message is displayed and you cannot proceed any further. In other browsers (Chrome, Opera, Edge, etc.) or when using other credit cards, the Facebook QR code for BC card payment is rendered without any problem.

If you are experiencing this, make sure that pop-ups are allowed for the *.payjoa.co.kr domain in Safari Preferences as shown below, and then try again.

Since PAYJOA internally uses Toss Payments - account transfer, account transfer is available only through Toss Simple Payment, NH Apps Cache, and direct input of account information. Entering account information directly requires security card/OTP authentication → public certificate authentication.

For mobile payment, account transfer payment is available only through Toss Simple Payment and NH Apps Cache.

When deposit is made to the (issued) virtual account, PAYJOA only reveals the name among the depositor’s information (bank name, account number, sender). Therefore, when you retrieve the i’mport payment details (GET /payments/{imp_uid}), the depositor’s bank code (bank_code) and bank name (bank_name) are both NULL. To get the depositor’s name, you must set the query parameter (extension) to true as follows:

// GET http://api.iamport.kr/payments/{i'mport number}?extension=true
{
  // ... Omitted
  "bank_code": null, // Depositor's bank code not provided
  "bank_name": null, // Depositor's bank name not provided
  "extension": {
    // ... Omitted
    "REMITTER": "John Doe" // Depositor's name
  }
}

Cancellation (refund) of payment for completed virtual account deposit is available only through a special contract with PAYJOA due to virtual account issuance fee issues. Refunds for virtual account payments cannot be processed without this contract.

Cancellation (refund) of PAYJOA virtual account payment is requested from the merchant → i’mport → PAYJOA. Since the refund is processed after a PAYJOA staff manually checks the request, it takes more than 7 business days for the refund amount to be deposited.

You need to request PAYJOA to issue the CPID on a case-by-case basis. In this way, all taxable/tax-free/combination transactions can be processed with one CPID.

When calling the payment window (IMP.request_pay function), you can set the tax-free amount (tax_free) out of the total amount (amount). In the PAYJOA system, the tax-free amount is only available when paying by card (pay_method: card). Account transfer and virtual account payments are taxed in full.

Customer’s phone number is not automatically filled in the escrow payment window

• Unlike other payment windows, the customer’s phone number (buyer_tel) passed into IMP.request_pay is not automatically filled in the escrow payment window. Note that PAYJOA does not support this function.