📍Precautions for using PAYJOA

Things to note when integrating PAYJOA

Returns success in PC and imp_success in mobile

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).

Session related issues when paying with Hana card/NH Apps Cache in Safari

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.

Issues when paying with BC card in Safari/Firefox

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.

Instant account transfer payment flow difference

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.

Only depositor's name can be accessed after virtual account deposit

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**
	}
}

Special contract with PAYJOA is required to cancel virtual account payment

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 of virtual account payment takes more than 7 business days to process

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.

Only one taxable/tax-free/combination CPID is issued for each case

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.

Tax-free amount can be set only for card payment

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.

PAYJOA bug

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.