🖥️Authenticated payment

Learn how to integrate authenticated payment through the PG payment window.

0. Definition

Authenticated payment refers to a payment method that requests a credit card payment with the authentication key after receiving the authentication result for payment from the PG. It is the most popular payment method in Korea. When a payment is requested from the checkout page, the payment window of each PG is presented to the user. Once payment is authenticated in the the payment module of the credit card company selected by the user, payment request is processed based on the authentication result.

Basic authenticated payment flow

Communication for a live payment request is made directly between the merchant server and the PG server, and card information is not used in the payment request process.

Authenticated payment is traditionally categorized into the following two types based on the authentication method.

  • ISP: authenticates pre-registered card information through a public key-based digital certificate

  • MPI: authenticates card information by entering the card number, CVC, and secure click password.

Recently, most credit card companies support their own simple payment service that allows users to pre-register a credit card and use the 6-digit payment password to easily make a payment.

NHN KCP authenticated payment - Shinhan Card simple pay window

You can easily integrate authenticated payments through i'mport!

1. Add i'mport library

Add the JS library to your checkout page.

You must first install jQuery 1.0 or later version.

2. Initialize IMP object

On the checkout page, initialize the IMP object using your Merchant ID.

3. Request payment

Once IMP object initialization is complete, you can open the payment window.

You can pass the parameters required to call the payment window in the first argument of the request_pay function.

Note - Creating an order ID (merchant_uid)

  • The order number must always be assigned a unique value each time the payment window is requested.

  • After the payment process is complete, the server uses the order ID to retrieve the order information for payment fraud check. Be sure to create a unique ID on the merchant server and store it in the DB.

The following is the above sample code with the Pay button added.

4-a. Process payment result (iframe)

When the payment process is completed successfully, you can receive the payment result depending on the payment window type as follows:

iframe
Popup

callback function

m_redirect_url

What is an iframe? It is a nested browser that effectively embeds another HTML page into the current page. By using the iframe element, other pages can be loaded and inserted into a web page without any restrictions.

iframe example

Most payments that are processed in the PC environment can receive payment results through the callback function, which is the second argument of the request_pay() function.

The following sample code processes the response to a payment request in a typical PC environment where the payment window is loaded as iframe.

Based on the the payment result (sucess/fail) in the response object (rsp) returned after the payment process is complete, add the post-payment processing logic in the callback function. When the payment is successful, add the logic to send the payment ID (imp_uid) and order ID (merchant_uid) to the server as shown above.

For information about the response parameter passed to the callback function, refer to rsp.

4-b. Process payment result (redirect)

The following sample code processes the response to a payment request in a typical mobile environment where the payment window is redirected to a new page to process the payment result.

If m_redirect_url is specified as the request_pay function parameter as above, the payment result is sent to the URL address in the form of a query string after payment is completed.

The following is an example of redirecting URL based on the query string.

Parameter
Description
Remarks

imp_uid

i'mport payment ID

Common

merchant_uid

Merchant order ID

Common

imp_success

Whether payment is successful

Common

error_code

Error code

Upon failure

error_msg

Error message

Upon failure

What does completion of the payment process mean?

The payment process is complete when:

  1. Payment is successful (Status: paid, imp_success: true)

  2. Payment fails (Status: failed, imp_success: false)

  3. Payment window fails to open due to PG module setting error

  4. User terminates the payment process by clicking the X or Cancel button

  5. Payment is suspended due to invalid card information, limit exceeded, insufficient balance, etc.

  6. Virtual account is issued (status: ready, imp_success: true)

5. Verify payment information

Based on the payment information from the client, the server verifies the payment amount for fraud and saves the payment information in the database if needed. The following are the steps for verifying the payment information.

  • Server receives the i'mport payment ID (imp_uid) and order ID (merchant_uid)

  • Call the Get payment API to get the payment details.

  • Based on the response, compare the actual payment amount with the payment request amount (from merchant's database).

STEP 01 Server receives payment result

Example of handling a POST request to the merchant endpoint URL that receives the payment information

STEP 02 Get payment details

Example of calling the Get payment API with the i'mport payment ID (imp_uid) to retrieve the payment info.

STEP 03 Verify payment information

Why fraud detection is necessary

Since the payment request is made on the client side, a payment request can be forged or falsified by manipulating the client script. Therefore, you must compare the original requested amount with the actual processed amount after the payment process is complete.

For example, when paying for a product that costs 100,000 won, an attacker can manipulate the client script to change the amount property to a value lower than the actual amount.

Since you cannot prevent script manipulation on the client, you must check for fraud on the server after the payment is processed.

Example of comparing the actual payment amount and the payment request amount, performing fraud check on the payment amount, and saving the data in the DB.

The original requested amount is queried from the database with the merchant_uid, and the actual processed amount is retrieved from the i'mport server with the imp_uid. The two values ​​are compared to verify that they match. If the verification is successful, the payment information is saved in the database and a response is returned based on the payment status (status). Otherwise, an error message is returned.

6. Complete payment

In a typical PC-environment payment processed using an iframe, the payment response can be received via a callback function. When the result processing is completed on the merchant server, the result message based on the success of the payment is returned as shown in the following example.

In a typical mobile environment payment processed by redirecting to a new page, process the payment complete message from the merchant endpoint URL set in the m_redirect_url parameter.

error_msg and error_code definitions

These parameters are returned as a response when the payment fails and they contains the same values returned from the PG without additional processing. Note that we don't yet provide definitions for the error codes and error messages that have accumulated in our system.

Last updated