Push Crypto

There are several things you need to consider when dealing with account top up requests in the Push Crypto method:

1. To verify the existence of the customer account, the payment platform sends the verify request to the web service URL using the HTTP method POST.
2. The request has the following parameters:
   • type—the operation type on the web service side (always verify)
   • customer_id—customer account ID within the web service used for topping up from the customer account within the cryptocurrency account topping up service
   • project_id—the project ID you obtained from Monetix
   • signature—the signature for the request.

   {
       "type": "verify",
       "project_id": 1234,
       "customer_id": "7123456789",
       "signature": "e19695449545fac562843ca06e7e0f3e51281ad6"
   }

3. You are required to send the response to the verify request synchronously. The response must contain the following parameters:
   • code—the response code
   • currency—the code of the purchase currency in the ISO-4217 alpha-3 format. This parameter is required for the 0 response code.

   Table 1. Valid response codes

   Code	Description
   0	Success
   400	Signature error
   404	The customer account does not exist
   500	General error, the reason must be specified in the message parameter

   Your response can contain the following additional parameters as well:

   • additional_customer_id—the unique customer ID used for the customer identification in the Monetix payment platform
   • message—the free-form description of the response code

   If the verification shows that the customer account exists, the response should contain the 0 response code to the request and the currency code. Here is an example of such a response:

   {
       "code": 0,
       "currency": "USD",
       "additional_customer_id": "customer_123"
   }

   If the request cannot be processed or the requested customer account is not found, the response should contain the 404 response code and the error description in the message parameter. Here is an example of such a response:

   { 
       "code": 404,
       "message": "Account does not exist"
   }

There are several things you need to consider when dealing with requests for the payment ID:

1. The payment platform sends the check_deposit request for the payment ID within the web service to the web service URL using the HTTP method POST.
2. The request contains the following parameters:
   • type—the operation type on the web service side (always check_deposit)
   • project_id—the project ID you obtained from Monetix
   • customer_id—ID of the customer web service account that the customer intends to top up
   • 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
   • payment_method—the payment method ID (always push/crypto)
   • signature—the signature for the request.

   {
       "type": "check_deposit",
       "project_id": 1234,
       "customer_id": "7123456789",
       "amount": 10000,
       "currency": "USD",
       "payment_method": "push/crypto",
       "signature": "lY0LTSAzpR7dOqRXJnL1kO0lUmkQ0YYLWRg=="
   }

3. You are required to respond to the check_deposit request synchronously. The response must contain the following parameters:
   • code—the response code
   • payment_id—the payment ID unique within the web service. This parameter is required for the 0 response code.

   Table 2. Valid response codes

   Code	Description
   0	Success
   400	Signature error
   404	The customer account does not exist
   500	General error, the reason must be specified in the message parameter

   Your response can have the following additional parameters as well:

   • message—the free-form description of the response code
   • description—the description of the payment

   Here is an example of the response to the request for the payment ID within the web service.

   {
       "code": 0,
       "payment_id": "payment_47",
       "description": "Success"
   }

   The response with an error must contain the response code and the description of the error in the message parameter. Here is an example of such a response:

   {
       "code": 500,
       "message": "Something went wrong"
   }