P2P transfers in Uzbekistan

Overview

P2P transfers in Uzbekistan is a payment method that allows customers to perform purchases by using bank P2P payments. P2P payments can be sent by using card numbers, mobile phone numbers, or by scanning QR codes. With P2P transfers in Uzbekistan, you can perform purchases by using Payment Page and Gate.

Download the logo in vector format here.
Payment method type Bank transfers
Countries and regions Uzbekistan
Payment currencies UZS
Currency conversion On the Monetix side
Purchases
Payouts
COF payments
Full refunds
Partial refunds
Chargebacks
Special considerations
  • If the customer enters an amount which is different from the amount specified in the purchase request, the payment is processed in a specific way described in the section Handling payments with amount changed by customer.
  • The payment instruction has an expiration date. If the customer makes a payment after the payment instruction is expired, the payment is declined or is assigned an intermediate status until the conflict is resolved manually by the Monetix technical support specialists.
  • The customer can use the payment details specified in the payment instruction only once. If the customer saves the payment details to make another payment later, such payment is declined or is assigned an intermediate status until the conflict is resolved manually by the Monetix technical support specialists.
Onboarding and access fee Refer to your key account manager at Monetix.

Interaction diagram

Payment processing by using the P2P transfers in Uzbekistan payment method requires the merchant web service, one of the Monetix interfaces, and the Monetix payment platform, as well as the provider's technical facilities.

Operations support

Interfaces Amounts, UZS Times
Payment Page Gate Dashboard minimum maximum basic threshold
Purchases * * * *

* Refer to your Monetix Key Account Manager for the information.

You can check the payment amount limits in your project by using Dashboard. To check your payment amount limits, go to Dashboard, select the Projects section and click the Payment methods tab.

Processing scenarios

In the P2P transfers in Uzbekistan payment method, to perform a purchase, you need to show your customer the payment instructions received from the provider service.

Figure 1. Purchase by using Payment Page
Figure 2. Purchase by using Gate

The sections that follow provide more information on how to perform payments and how you can analyze payments and operations information.

Purchase by using Payment Page

General information

In the P2P transfers in Uzbekistan method, when processing a purchase by using Payment Page, the merchant web service sends a request with all the required parameters and signature to the Monetix URL and accepts the callback with the payment result from the payment platform.

When opening Payment Page, you can have Payment Page opened with the P2P transfers in Uzbekistan method pre-selected. (For more information about pre-selecting payment methods, see Preselecting payment methods.)

The full sequence of the purchase workflow is provided below.

Figure 3. Purchase workflow when using Payment Page
  1. The customer initiates a purchase on the merchant's web service.
  2. The web service sends the request for the Payment Page opening to the Monetix URL.
  3. The request for opening Payment Page is redirected to the payment platform.
  4. The payment platform performs the initial request processing that includes validation whether all the required parameters are available and signature is correct.
  5. The requested Payment Page is generated by the Monetix payment platform as specified in the project settings and request parameters.
  6. Payment Page is displayed to the customer.
  7. The customer selects P2P transfers in Uzbekistan as the payment method.
  8. The payment platform receives the purchase request for the payment processing from Payment Page.
  9. The payment platform performs the internal purchase request processing and forwards it to the provider service.
  10. The provider service processes the purchase request.
  11. The provider service generates the data for displaying the payment instructions and sends it to the payment platform.
  12. The payment platform sends the payment instructions data to Payment Page.
  13. The payment instructions are displayed to the customer.
  14. The customer completes the payment by following the payment instructions.
  15. The provider service processes the payment.
  16. The provider service sends the result notification to the payment platform.
  17. The payment platform sends a callback with the payment result to the web service.
  18. The payment platform sends the result to Payment Page.
  19. The page with the payment result information is displayed to the customer on Payment Page.

The sections that follow discuss in more details the request format and the Payment Page parameters to use in the P2P transfers in Uzbekistan payment method and provide the information about the format of callbacks with payment results. For the general information about how to use the Payment Page API, see Payment Page API Description.

Request format

There are several things you need to consider when dealing with purchase requests in the P2P transfers in Uzbekistan method:

  1. You must provide values for the basic minimum of parameters. Listed below are the parameters that are required for any payment method:
    • project_id—project ID you obtained from Monetix
    • payment_id—payment ID unique within the project
    • customer_id—the unique ID of the customer within your project
    • customer_first_name—customer first name
    • customer_last_name—customer last name
    • customer_email—customer email
    • payment_currency—payment currency in ISO-4217 alpha-3 format
    • payment_amount—payment amount in minor currency units without any decimal point or comma except for cases where the currency does not have any minor currency units. If the currency has no minor units (that is, the number of digits for minor currency units is zero), then you must set this parameter to the amount in the major currency units. For the information on whether the currency has any minor units, see Currency codes.
  2. If you need to have the payment form displayed with the P2P transfers in Uzbekistan method pre-selected, set the force_payment_method parameter to the code on the card-p2p payment method.
  3. You can also add any other additional parameters Payment Page supports. For more information about parameters supported by Payment Page, see Payment Page invocation parameters.
  4. After you specify all the parameters you need, you must create the signature for the request. For instructions on how to sign payment requests, see Signature generation and verification.

Here is an example of the data from a request for the Payment Page opening:

EPayWidget.run(
    {
        project_id: 1234, 
        payment_id: 'payment_47',
        customer_id: 'customer_123',
        customer_first_name: 'John',
        customer_last_name: 'Doe',
        customer_email: 'johndoe@email.com',
        payment_currency: 'UZS',
        payment_amount: 3000000,
        signature: 'kUi2x9dKHAVNU0FYldJrxh4yo+52Kt8KU+Y19vySO\/RLUkDJrOcZzUCwX6R\/ekpZhkIQg=='
    }
)

Callback format

The P2P transfers in Uzbekistan method uses the standard format for callbacks to deliver purchase results. For more information about callbacks, see Callbacks in Payment Page.

The following is an example of a callback with information about a successful 30,000.00 UZS purchase.

Figure 4. Example of the data from a successful purchase callback
{
    "project_id": 1234,
    "payment": {
        "id": "payment_47",
        "type": "purchase",
        "status": "success",
        "date": "2022-03-25T11:08:45+0000",
        "method": "card-p2p",
        "sum": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "description": ""
    },
    "customer": {
        "id": "customer_123"
    },
    "operation": {
        "id": 28,
        "type": "sale",
        "status": "success",
        "date": "2022-03-25T11:08:45+0000",
        "created_date": "2022-03-25T11:08:05+0000",
        "request_id": "9e32835fb27907e0b08569d7d150e387a16a80e336c5117242b5cf60a4e17839",
        "sum_initial": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "sum_converted": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "code": "0",
        "message": "Success",
        "provider": {
            "id": 12345,
            "payment_id": "123abc123-321",
            "auth_code": ""
        }
    },
    "signature": "U7HQO7ToISZhMPKdM4Xr4DSX2UuHp99rHrtaxkUKQtoYzFvoB3cs9CRd4xeYG2Q=="
}

The following is the example of a callback for a declined purchase.

Figure 5. Example of the data from a declined purchase callback
{
    "project_id": 1234,
    "payment": {
        "id": "payment_47",
        "type": "purchase",
        "status": "decline",
        "date": "2022-03-25T11:20:30+0000",
        "method": "card-p2p",
        "sum": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "description": ""
    },
    "customer": {
        "id": "customer_123"
    },
    "operation": {
        "id": 31,
        "type": "sale",
        "status": "decline",
        "date": "2022-03-25T11:20:30+0000",
        "created_date": "2022-03-25T11:19:53+0000",
        "request_id": "fff3d5f8d5d31bc460b68b57dc63f4b482e906eb",
        "sum_initial": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "sum_converted": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "code": "20000",
        "message": "General decline",
        "provider": {
            "id": 15923,
            "payment_id": "0cf4215c-8978",
            "auth_code": ""
        }
    },
    "signature": "J7W15rkqrLzTCD4HkoM4qoEnlVlfqz8155QSlXJKR4m8C4z2iFYv58P4VnHANu445/jmY+g=="
}

Related topics

The following topics might be useful when implementing payments through Payment Page:

Purchase by using Gate

General information

In the P2P transfers in Uzbekistan method, the merchant web service is required to do the following when processing a purchase by using Gate:

  1. Send a request with all the required parameters and signature to the Monetix URL.
  2. Show the screen with the payment instructions to the customer.
  3. Accept the callback with the payment result from the payment platform.

The following diagram provides the detailed picture of the payment processing procedure.

Figure 6. Purchase workflow when using Gate
  1. The customer initiates a purchase with P2P transfers in Uzbekistan on the merchant's web service side.
  2. The web service sends a request for processing the purchase by using Gate to the Monetix URL.
  3. The payment platform receives the request for processing the purchase from Gate.
  4. The payment platform performs the initial request processing that includes validation whether all the required parameters are available and signature is correct.
  5. The payment platform sends the response with the request receipt confirmation and validation result to the web service. For more information about the response format, see Response structure.
  6. The payment platform performs the internal payment request processing and redirects the request to the provider service.
  7. The provider service processes the request.
  8. The provider service generates the data for displaying payment instructions and sends it to the payment platform.
  9. The payment platform sends the callback with the payment instructions data inside the display_data array to the web service.
  10. The payment instructions are displayed to the customer.
  11. The customer completes the payment by following the payment instructions.
  12. The provider service processes the payment.
  13. The provider service sends the payment result notification to the payment platform.
  14. The payment platform sends the callback with the payment result to the web service.
  15. The web service sends the payment result to the customer.

The sections that follow discuss in more details the request format and the Gate parameters to use in the P2P transfers in Uzbekistan payment method and provide the information about the format of callbacks with purchase results. For the general information on how to use the Gate API, see API Description.

Request format

There are several things you need to consider when dealing with purchase requests in the P2P transfers in Uzbekistan method:

  1. You initiate a purchase by submitting a purchase request to the /v2/payment/card-p2p/sale endpoint by using the HTTP method POST.
  2. The following objects and parameters must be specified in any request:
    • general—object with general request identification information:
      • project_id—the project ID you obtained from Monetix
      • payment_id—payment ID unique within the project
      • signature—signature created after you specify all the required parameters. For more information about signature generation, see Signature generation and verification.
    • customer—object with customer information:
      • id—the unique ID of the customer within your project
      • ip_address—IP address of the customer's device
      • first_name—customer first name
      • last_name—customer last name
      • email—customer email
    • payment—object with purchase information:
      • amount—purchase amount in minor currency units without any decimal point or comma except for cases where the currency does not have any minor currency units. If the currency has no minor units (that is, the number of digits for minor currency units is zero), then you must set this parameter to the amount in the major currency units. For the information on whether the currency has any minor units, see Currency codes.
      • currency—code of the purchase currency in the ISO-4217 alpha-3 format.
      • by_method—the code of the payment option your customer chooses to make a payment. Refer to your Monetix key account manager to find out whether this parameter is relevant to you.

        Possible values are:

        • card-p2p—if the customer chooses Transfer to card
        • sbp-p2p—if the customer chooses Transfer by phone number
        • sbp-qr—if the customer chooses Transfer by QR code
  3. You can also pass the payment system code of the card your customer uses to make a purchase with in the option parameter of the payment object. This parameter is not required. You only have to add it to the request after the by_method parameter with the card-p2p value.

    Possible values of the option parameter:

    • humo—if the customer uses a card of the HumoCard payment system
    • uzcard—if the customer uses a card of the UZCARD payment system
  4. If required, you can add any other additional (optional) parameters Gate supports.

Here is an example of the data from a purchase request in the P2P transfers in Uzbekistan method.

Figure 7. Example of the data from a purchase request
{
    "general": {
        "project_id": 1234,
        "payment_id": "payment_47",
        "signature": "PJkV8ej\/UG0Di8hTng6JvC7vQsaC6tajQVVfBaNIipTv+AWoXW\/9MTO8yJA=="
    },
    "customer": {
        "id": "customer_123",
        "ip_address": "198.51.100.47",
        "first_name": "John",
        "last_name": "Doe",
        "email": "johndoe@example.com"
    },
    "payment": {
        "amount": 3000000,
        "currency": "UZS",
        "by_method": "sbp-p2p",
        "option": "humo"
    }
}

Format of data for displaying the payment instruction

Before displaying the screen with payment instructions to the customer, you must accept a callback from the payment platform with the payment instructions data in the display_data array—only after this you can display the screen with payment instructions to the customer.

Each element of the display_data array contains the following parameters:

  • type—element type (always add_info)
  • title—the name of the payment instruction data, can take the following values:
    • amount—purchase amount in minor currency units without any decimal point or comma
    • receiver_account—transfer recipient's account number
    • receiver_name—transfer recipient's full name
    • currency—code of the purchase currency in the ISO-4217 alpha-3 format
    • lifetime—lifetime of the payment instructions (in seconds)
    • payment_option—the payment system code of the card your customer uses to make a payment with
    • qr_data—link to the QR code for payment
  • data—payment instruction data
Note: Note: There are some specifics concerning the payment instructions display:
  • The payment details should be displayed to the customer only while it is valid (within its lifetime). The payment details should be hidden after the period of its validity is expired.
  • Structure of the display_data array depends on the value of the by_method parameter that was submitted in the initial purchase request.
  • The payment_option parameter may not be present in the display_data array.

Here is an example of the callback fragment containing the data to display the payment instructions to the customer:

"display_data": [
    {
        "type": "add_info",
        "title": "amount",
        "data": 3000000
    },
    {
        "type": "add_info",
        "title": "receiver_account",
        "data": "998123456789"
    },
    {
        "type": "add_info",
        "title": "receiver_name",
        "data": "John Doe"
    },
    {
        "type": "add_info",
        "title": "currency",
        "data": "UZS"
    },
    {
        "type": "add_info",
        "title": "lifetime",
        "data": 480
    },
    {
        "type": "add_info",
        "title": "payment_option",
        "data": "humo"
    }
]

Callback format

The P2P transfers in Uzbekistan method uses the standard format for callbacks to deliver purchase results. For more information about callbacks, see Callbacks in Gate.

The following is an example of a callback with information about a successful 30,000.00 UZS purchase.

Figure 8. Example of the data from a successful purchase callback
{
    "project_id": 1234,
    "payment": {
        "id": "payment_47",
        "type": "purchase",
        "status": "success",
        "date": "2022-03-25T11:08:45+0000",
        "method": "card-p2p",
        "sum": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "description": ""
    },
    "customer": {
        "id": "customer_123"
    },
    "operation": {
        "id": 28,
        "type": "sale",
        "status": "success",
        "date": "2022-03-25T11:08:45+0000",
        "created_date": "2022-03-25T11:08:05+0000",
        "request_id": "9e32835fb27907e0b08569d7d150e387a16a80e336c5117242b5cf60a4e17839",
        "sum_initial": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "sum_converted": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "code": "0",
        "message": "Success",
        "provider": {
            "id": 12345,
            "payment_id": "123abc123-321",
            "auth_code": ""
        }
    },
    "signature": "U7HQO7ToISZhMPKdM4Xr4DSX2UuHp99rHrtaxkUKQtoYzFvoB3cs9CRd4xeYG2Q=="
}

The following is the example of a callback for a declined purchase.

Figure 9. Example of the data from a declined purchase callback
{
    "project_id": 1234,
    "payment": {
        "id": "payment_47",
        "type": "purchase",
        "status": "decline",
        "date": "2022-03-25T11:20:30+0000",
        "method": "card-p2p",
        "sum": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "description": ""
    },
    "customer": {
        "id": "customer_123"
    },
    "operation": {
        "id": 31,
        "type": "sale",
        "status": "decline",
        "date": "2022-03-25T11:20:30+0000",
        "created_date": "2022-03-25T11:19:53+0000",
        "request_id": "fff3d5f8d5d31bc460b68b57dc63f4b482e906eb",
        "sum_initial": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "sum_converted": {
            "amount": 3000000,
            "currency": "UZS"
        },
        "code": "20000",
        "message": "General decline",
        "provider": {
            "id": 15923,
            "payment_id": "0cf4215c-8978",
            "auth_code": ""
        }
    },
    "signature": "J7W15rkqrLzTCD4HkoM4qoEnlVlfqz8155QSlXJKR4m8C4z2iFYv58P4VnHANu445/jmY+g=="
}

Related topics

The following topics might be useful when implementing payments through Gate:

Analysis of payments results

As with other payment methods Monetix offers, when using this method, you have several options to analyze the information about payments and operations.

You can load and analyze all the necessary information in Dashboard (dash-light.trxhost.com), for instance you can use the analytic panels in the Analytics section for this purpose.

Also, you can export the information for further analysis by using third party analytical tools. The following options are available:

  • Dashboard allows you to download reports in CSV format by using the tools in the Reports section. You can perform export as a one-time or regular download of data to your local computer.
  • Data API allows you to have payment information exported in JSON format and delivered to a URL you specify. The payment information is exported by means of sending requests to the /operations/get endpoint.

If you have any further questions regarding payment data analysis, contact Monetix technical support.