Home Currency Conversion ECOMMPAY Documentation

ECOMMPAY Documentation

0

Normal data

WebMoney

methodology, there are a number of buy situations:

  • The

    WebMoneyLight

    buy—buyer redirection to the

    WebMoney

    type.

  • The

    WebMoneyClassic

    buy—buyer invoicing within the service provider internet service.

  • The

    WebMoneyClassic

    buy utilizing the

    X20

    interface—buyer pays with out leaving

    Fee Web page

    , confirming the acquisition by utilizing code from the SMS or paying an bill

In themethod, there are a number of buy situations:

You’ll be able to eneble totally different situations for the initiatives, for extra data contact the important thing account supervisor ECommPay. When processing any of the acquisition situations by utilizing Fee Web page, the service provider internet service is required to ship a request with all of the required parameters and signature to the ECommPay URL and get the callback with the cost outcome from the cost platform. When opening Fee Web page, you’ll be able to both permit your buyer to pick out the WebMoneyLight or WebMoneyClassic buy from the checklist of different cost strategies on Fee Web page or have Fee Web page opened with one among them chosen. For extra details about preselecting cost strategies, see Preselecting cost strategies.

The next diagrams present the detailed image of the cost processing process.

Determine: The WebMoneyLight buy sequence when utilizing Fee Web page

  1. Buyer initiates buy by utilizing the online service.
  2. The service provider internet service sends to the required

    ECommPay

    URL the acquisition request for processing the acquisition by utilizing

    Fee Web page

    .

  3. The cost platform receives the request for processing the acquisition by utilizing

    Fee Web page

    .

  4. The cost platform performs the preliminary request processing that includes validation of the required parameters and signature.
  5. Requested

    Fee Web page

    is generated into the

    ECommPay

    cost platform as specified within the venture settings and the request parameters.

  6. Fee Web page

    is exhibited to the client.

  7. The client selects the

    WebMoneyLight

    buy from the checklist of different cost strategies and agrees to make use of the tactic (or accepts the tactic already chosen on

    Fee Web page

    and agrees).

  8. The cost platform receives the acquisition request for cost processing within the

    WebMoney

    service.

  9. The cost platform performs the inner buy request processing and sends it to the

    WebMoney

    service.

  10. The acquisition request is processed within the

    WebMoney

    service.

  11. The

    WebMoney

    service generates the information for redirecting the client to the

    WebMoney

    type and sends it to the cost platform.

  12. The cost platform sends to

    Fee Web page

    the information for redirecting the client to the

    WebMoney

    type.

  13. The client is redirected to the

    WebMoney

    type.

  14. The client completes all of the cost steps required by the

    WebMoneyLight

    buy methodology.

  15. The cost is processed within the

    WebMoney

    service.

  16. The cost outcome data is exhibited to the client on the

    WebMoney

    type. The client initiates redirection to the outcome ready web page on

    Fee Web page

    .

  17. The

    WebMoney

    service sends the cost outcome notification to the cost platform.

  18. The cost platform sends the callback to the online service.
  19. The cost platform sends cost outcomes to

    Fee Web page

    .

  20. A web page with the cost outcome data is exhibited to the client.

Determine: The WebMoneyClassic buy sequence when utilizing Fee Web page

  1. Buyer initiates buy by utilizing the online service.
  2. The service provider internet service sends to the required

    ECommPay

    URL the acquisition request for processing the acquisition by utilizing

    Fee Web page

    .

  3. The cost platform receives the request for processing the acquisition by utilizing

    Fee Web page

    .

  4. The cost platform performs the preliminary request processing that includes validation of the required parameters and signature.
  5. Requested

    Fee Web page

    is generated into the

    ECommPay

    cost platform as specified within the venture settings and the request parameters.

  6. Fee Web page

    is exhibited to the client.

  7. The client selects the

    WebMoneyClassic

    buy from the checklist of different cost strategies and agrees to make use of the tactic (or accepts the tactic already chosen on

    Fee Web page

    and agrees).

  8. The cost platform receives the acquisition request for cost processing within the

    WebMoney

    service.

  9. The notification is exhibited to buyer and comprises data that it’s required to go to the

    WebMoney

    Keeper service and pay the bill.

  10. The cost platform performs the inner buy request processing and sends it to the

    WebMoney

    service.

  11. The

    WebMoney

    service performs the acquisition request processing and points the bill.

  12. The the

    WebMoney

    service sends to the cost platform response contained bill issuing affirmation.

  13. The client makes use of the

    WebMoney

    Keeper service to pay the bill.

  14. The cost is processed within the

    WebMoney

    service.

  15. The

    WebMoney

    service sends the cost outcome notification to the cost platform.

  16. The cost platform sends the callback to the online service.
  17. The cost platform sends cost outcomes to

    Fee Web page

    .

  18. A web page with the cost outcome data is exhibited to the client.

Determine: The WebMoneyClassic buy utilizing the X20 interface

  1. Buyer initiates buy by utilizing the online service.
  2. The service provider internet service sends to the required

    ECommPay

    URL the acquisition request for processing the acquisition by utilizing

    Fee Web page

    .

  3. The cost platform receives the request for processing the acquisition by utilizing

    Fee Web page

    .

  4. The cost platform performs the preliminary request processing that includes validation of the required parameters and signature.
  5. Requested

    Fee Web page

    is generated into the

    ECommPay

    cost platform as specified within the venture settings and the request parameters.

  6. Fee Web page

    is exhibited to the client.

  7. The client selects the

    WebMoneyClassic

    buy from the checklist of different cost strategies and agrees to make use of the tactic (or accepts the tactic already chosen on

    Fee Web page

    and agrees).

  8. The client selects the identification methodology (telephone quantity, e-mail deal with, or WMID) and affirmation methodology (code from SMS or WM bill).
  9. The cost platform receives the acquisition request for cost processing within the

    WebMoney

    service.

  10. The notification is exhibited to buyer and comprises data that it’s required to go to the

    WebMoney

    Keeper service and pay the bill.

  11. The cost platform performs the inner buy request processing and sends it to the

    WebMoney

    service.

  12. The

    WebMoney

    service performs the acquisition request processing and generates knowledge for the acquisition affirmation.

  13. The client receives SMS with affirmation code or details about bill.
  14. The purchasers confirms the acquisition:
    • when selecting SMS—enters code from SMS on

      Fee Web page

      or makes use of the

      WebMoney

      Keeper service to pay the bill.

    • when selecting WM bill—makes use of the

      WebMoney

      Keeper service to pay the bill.

  15. The cost is processed within the

    WebMoney

    service.

  16. The

    WebMoney

    service sends the cost outcome notification to the cost platform.

  17. The cost platform sends the callback to the online service.
  18. The cost platform sends cost outcomes to

    Fee Web page

    .

  19. A web page with the cost outcome data is exhibited to the client.

The sections that observe focus on in additional particulars the request format and the Fee Web page parameters to make use of within the WebMoney methodology and supply the data on the format of callbacks with cost outcomes. For the overall data on use the API, see Fee Web page API Description.

Request format for purchases by utilizing

WebMoneyLight

or

WebMoneyClassic

There are a number of issues it’s essential contemplate when utilizing the WebMoney
methodology:

  1. You could present values for the fundamental minimal of parameters. Listed under are the parameters which are obligatory for any cost methodology:
    • project_id

      —the venture ID obtained from

      ECommPay

    • payment_id

      —cost ID distinctive throughout the venture

    • payment_currency

      —cost forex in ISO-4217 alpha-3 format

    • payment_amount

      —cost quantity in minor items

    • customer_id

      —buyer ID distinctive throughout the venture

  2. Moreover, it’s essential use the next parameters:
    • payment_description

      —cost description.

      Fee description ought to be specified within the request as follows: High-up of private account №<buyer's checking account quantity> on the web site <URL of the service provider internet service>. Instance: High-up of private account №01234567890 on the web site https://merchant.example.com/

  3. If it’s essential have

    Fee Web page

    displayed with the

    WebMoneyLight

    or

    WebMoneyClassic

    buy methodology chosen, set the

    force_payment_method

    parameter to:

    • webmoney-light—the

      WebMoneyLight

      buy methodology

    • webmoney—the

      WebMoneyClassic

      buy methodology

  4. If required, you may also add another further parameters

    Fee Web page

    helps.

  5. After you specify all of the parameters you want, it’s essential to create the signature for the request. For directions on signal a cost request, see Signature era and verification.

Thus, an accurate cost request within the WebMoney methodology should embody venture, cost and buyer IDs, forex and quantity of a cost within the applicable forex, cost description, and signature, as proven within the following instance:

EPayWidget.run({
      payment_id: 

'ECT_TEST_1534835032773,

payment_amount:

100

, payment_currency:

'USD'

, project_id:

238

, customer_id:

'customer1'

, payment_description:

'High-up of private account №01234567890 on the web site https://merchant.example.com/'

, signature:

"2tlMuYxLW9Yu6RETr8pdCfmi0UPE8euD+2QgJ...=="

})

For details about all parameters out there within the WebMoney methodology, see Fee Web page invocation parameters.

Request format for purchases by utilizing the

WebMoneyClassic

methodology with the

X20

interface

There are a number of issues it’s essential contemplate when utilizing the WebMoneyClassic methodology with the X20 interface:

  1. You could present values for the fundamental minimal of parameters. Listed under are the parameters which are obligatory for any cost methodology:
    • project_id

      —the venture ID obtained from

      ECommPay

    • payment_id

      —cost ID distinctive throughout the venture

    • payment_currency

      —cost forex in ISO-4217 alpha-3 format

    • payment_amount

      —cost quantity in minor items

    • customer_id

      —buyer ID distinctive throughout the venture

  2. Moreover, it’s essential use the next parameters:
    • customer_account_number

      —buyer identifier within the

      WebMoney

      service (WMID, e-mail deal with, or telephone quantity within the 7XXXXXXXXXX or 7XXXXXXXXXX format)

    • payment_description

      —cost description.

      Fee description ought to be specified within the request as follows: High-up of private account №<buyer's checking account quantity> on the web site <URL of the service provider internet service>. Instance: High-up of private account №01234567890 on the web site https://merchant.example.com/

  3. If it’s essential have

    Fee Web page

    displayed with the one

    WebMoneyClassic

    buy methodology chosen, set the

    force_payment_method

    parameter to webmoney.

  4. If required, you may also add another further parameters

    Fee Web page

    helps.

  5. After you specify all of the parameters you want, it’s essential to create the signature for the request. For directions on signal a cost request, see Signature era and verification.

Thus, an accurate cost request within the WebMoney methodology should embody venture, cost and buyer IDs, forex and quantity of cost within the applicable forex, cost description, buyer identifier within the WebMoney service, and signature, as proven within the following instance:

EPayWidget.run({
      project_id: 

123456

, payment_id:

'1234123'

, customer_id:

'456QWE'

, payment_amount:

1000

, payment_currency:

'USD'

, payment_description:

'High-up of private account №01234567890 on the web site https://merchant.example.com/'

, customer_account_number:

'79528618748'

, signature:

"rVCiAULmqzRsNiVm2I8l3ip03YdAnpY%2F%2F7dKte36gD2GNNfu%2FrAGIAhfTQ8v..."

})

For details about all parameters out there within the WebMoney methodology, see Fee Web page invocation parameters.

Callback format

Within the WebMoney methodology, the callbacks that ship buy outcomes use the usual format described in Callbacks.

Word that not like different cost strategies, within the WebMoney methodology, the callbacks embody the cost ID that’s generated by the WebMoney service and is handed within the payment_id parameter of the supplier object. The profitable buy callbacks at all times include the payment_id parameter worth, however the declined buy callbacks might not include the parameter worth.

The next instance of callback comprises an details about profitable 1.00 USD
WebMoneyClassic buy made within the 238 venture by utilizing the R123456890000 buyer WM pockets. Fee ID generated by the WebMoney service is 1592901328.

Determine: Instance of a profitable WebMoneyClassic buy callback

{
	

"project_id"

:

238

,

"payment"

: {

"id"

:

"ECT_TEST_1534835032773"

,

"type"

:

"purchase"

,

"status"

:

"success"

,

"date"

:

"2018-08-21T07:05:53+0000"

,

"method"

:

"webmoney"

,

"sum"

: {

"amount"

:

100

,

"currency"

:

"USD"

},

"description"

:

"ECT_TEST_1534835032773"

},

"account"

: {

"number"

:

"R703276019842"

},

"operation"

: {

"id"

:

167000001094

,

"type"

:

"sale"

,

"status"

:

"success"

,

"date"

:

"2018-08-21T07:05:53+0000"

,

"created_date"

:

"2018-08-21T07:05:12+0000"

,

"request_id"

:

"765fc31fbb98a4ac937bbdadb3303f1d13eead

ec -

917

f825e85cce20981b0686599cb14b7f383d0e6

",

"sum_initial"

: {

"amount"

:

100

,

"currency"

:

"USD"

},

"sum_converted"

: {

"amount"

:

100

,

"currency"

:

"USD"

},

"provider"

: {

"id"

:

1082

,

"payment_id"

:

"1592901328"

,

"date"

:

"2018-08-21T10:05:51+0000"

,

"auth_code"

:

""

},

"code"

:

"0"

,

"message"

:

"Success"

},

"signature"

:

"nEIk8lTBATPQXhZAqkiEzraA88Tgjx45cPP18thE/9iEkS

lE9TS20z01H7 /

8

nvHU2Dz + Dp1goRozWpQRXmL6jA ==

"

}

The next instance of callback is for a cost rejected attributable to quantity or frequency limitation and doesn’t include the cost ID generated by the WebMoney service.

Determine: Instance of a declined WebMoneyLight buy callback

{
	

"project_id"

:

238

,

"payment"

: {

"id"

:

"ECT_TEST_154477095843411111"

,

"type"

:

"purchase"

,

"status"

:

"decline"

,

"date"

:

"2018-12-14T09:41:30+0000"

,

"method"

:

"webmoney-light"

,

"sum"

: {

"amount"

:

1000000000

,

"currency"

:

"USD"

},

"description"

:

"ECT_TEST_154477095843411111"

},

"operation"

: {

"id"

:

13290000002280

,

"type"

:

"sale"

,

"status"

:

"decline"

,

"date"

:

"2018-12-14T09:41:30+0000"

,

"created_date"

:

"2018-12-14T08:41:29+0000"

,

"request_id"

:

"a52dc11e9d57fa3a8649671e5599544fcfc50d

f - ebbce425f52073d89f96c67686feefe5ab01c1fd

",

"sum_initial"

: {

"amount"

:

100

,

"currency"

:

"USD"

},

"sum_converted"

: {

"amount"

:

100

,

"currency"

:

"USD"

},

"provider"

: {

"id"

:

1083

,

"payment_id"

:

""

,

"auth_code"

:

""

},

"code"

:

"20101"

,

"message"

:

"Decline due to amount or frequency limit"

},

"signature"

:

"ukUg6gJ6RtUc2qeXTNE+iDyEh4HdikHuMaCZ4Hju

sN + uJA8Ze7RVztvlyWhtiXUjrL14pplG7ustFhJIJdDkvw ==

"

}
See also  Change DAG witness server and witness directory