BASICS:

1. BASICS:

• 1.1. Services
• 1.2. Identification
• 1.3 Types and global rules
• 1.4 Schemes
• 1.5 Order and operations on it
• 1.6 Confirmation
• 1.7 Order processing
• 1.8 Customer notification about complied authorization
• 1.9 Obtaining processing status and results
• 1.10 Obtaining payment mail notification
• 1.11 Liability levels

2. ORDER REGISTRATION:

• 2.1 Register_simple method

3. ORDER STATUS RETRIEVE

• 3.1 Get_status method
• 3.2 Get_by_order method

4. ORDER CONFIRMATION:
5. ORDER CANCELATION
6. ORDER REJECT
7. PAYMENT REFUND
8. REFERENCES

• 8.1. REQUEST PROCESSING SOAP FAULT CODES
• 8.2. ORDER PROCESSING ERRORS CODES
• 8.3.ORDER STATUS
• 8.4 EVENT CODES
• 8.5 3DS AUTHENTICATION STATUS
• 8.6 User interface language
• 8.7 Payment session types
• 8.8 Card codes
• 8.9 Card data input modes (ChoosenPayMode)

1. BASICS:

Store system communicates with Payment gateway using web-services.

1.1. Services

There are four web-services provided for access from Store system to Payment gateway:

1. order - managing payment orders
2. status - retrieving orders processing status
3. check - retrieving mail notifications
4. ticket - retrieving information about issued tickets

Payment gateway conforms to the following industry standards and protocols:

• Message Envelope: SOAP 1.1
• Message Transfer: HTTP 1.1
• Encryption: TLS 1.1 or TLS 1.2
• Web Service Description Language: WSDL 1.1
• Data Transfer: XML 1.0
• Encoding: UTF-8

1.2. Identification

Basic HTTP authorisation is required for any request. The Store system will be provided with test and production access credentials - login and password or certificate. Access to Payment gateway services can be limited by the list of ip addresses on the basis of security factor. Store is also provided with shop_id - special unique Store identifier in Payment gateway system for request performance.

Note: shop_id is not equal to Acquirer terminals (MID/TID). Shop_id is used to perform operations with the order, while Acquirer terminals are used to complete authorization.

1.3 Types and global rules

Float type parameters values must be separated with dot (“.”) symbol. This rule is especially relevant to amount parameter in which major monetary unit (e.g. rubles) and minor monetary unit (e.g. kopecks) must be separated by dot.

Datetime parameter values must be in UTC timezone format.

Blank space is also a symbol.

The general timeout for responses is 30 seconds. Average services method call response time equate 2-3 seconds.

In case of SOAP fault the faultstring field will contain an error code (p. 8.1). Store system will receive SOAP fault to incorrect by scheme or by values request.

Example:

<soap-env:Envelope
    xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
     <soap-env:Body>
        <soap-env:Fault>
            <faultcode>Server</faultcode>
            <faultstring>Internal Server Error</faultstring>
            <detail />
        </soap-env:Fault>
     </soap-env:Body>
</soap-env:Envelope>

1.4 Schemes

There are 2 basic schemes of card data entry:

1. payment-gateway-side: all card PCI-DSS sensitive data entering on Payment gateway side, and can’t be provided in full form into Store system.
2. store-system-side: for PCI-DSS certified merchants have an option to enter card data on own side and provide it from Store system to Payment gateway.

For payment-gateway-side Payment gateway support only re-direct mechanic. On order registration request (in register method response) Store system will receive re-direct url to perform Customer browser re-direct to this url. This url will land Customer to secure Payment gateway page and card data entry will be made on secured Payment gateway side.

For store-system-side Payment gateway support 2 mechanics:

1. browser-to-host: Store system on own payment page have to embed special Payment gateway code and call it to send card data from Customer web browser to Payment gateway host.
   
2. host-to-host: Store system collect card data from Customer browser to its own host itself and transfer from it to Payment gateway.

1.5 Order and operations on it

Order is Payment gateway primary entry, and represents settlement acts between Store and Customer in context of their deal.

Acts are:

1. When the Customer make a Payment to Store.
2. When the Store make a Refund to Customer.

The Payment may have the following stages:

1. Authorization - Customer’s bank holds amount of money on Customer’s account. After this Payment gateway mark order as payed.
2. Charge - Customer’s bank charges amount of money Customer’s account. This stage may be reached only in process of settlement between Store and Acquirer.

The Store system initiate operations on order by calling proper order service methods. Payment gateway supports:

1. register - to initiate the Payment;
2. cancel - to interrupt the Payment before authorization stage;
   
3. reject - to interrupt the Payment after authorization stage and before order confirmation (p. 1.6);
4. confirm - as described in p. 1.6;
5. refund - to make refund to Customer.

1.6 Confirmation

Confirmation is the process of informing that Payment gateway have to start settlement initiation process between Store and Acquirer. Before the order is confirmed, Payment gateway system holds money authorization on Customer bank account without charging of it. After sending confirmation, capture process begins and Payment gateway schedules payment settlement process.

Payment gateway system supports 2 basic configuration of confirmation:

1. auto - Payment gateway system will schedule settlement process right after the order is payed, this is default configuration.
2. manual - Payment gateway system will schedule settlement process only after receiving confirm request from Store system.

Store has a 2 options for setup Payment gateway reaction on expiry time of confirmation awaiting:

1. confirm-on-expire - will force automatic scheduling confirmation for all unconfirmed orders.
2. cancel-on-expire - will cancel all all unconfirmed orders.

Note: Store may configure expiration period, ask Support Team for this.

1.7 Order processing

A set of activities in order processing depends on

1. Card entry scheme (p. 1.4)
2. 3d-secure enable status
3. fraudcheck enable status

and consists of the:

1. (optional, only in payment-gateway-side scheme) Card data entry on Payment gateway secure page (avg. 1-3 min)
2. (optional, only for 3d-secure enabled) Payment gateway request Customer’s bank for enrolment Customer’s card in 3d-secure program (avg. 2-10 secs)
3. (optional, only for 3d-secure enabled) Customer passing 3d-secure authentication procedures, as usual Customer receive and enter secure code on Customer’s bank page (avg. 1-2 min)
4. (optional, only for fraudcheck enabled) Fraud management procedures (avg. 1-2 sec)
5. Payment gateway request Customer’s bank for authorization of Payment (avg. 2-5 sec).

Note: Store system can set Customer browser re-direct pages settings, to assign web pages to which Payment gateway will initiate Customer browser re-direct after successful or unsuccessful order processing completion. If Store request has no re-direct pages settings, Customer will be re-directed to Store home page, registered in Payment gateway database.

Tip: If Store system want to use timelimit to limit total time of processing, it has to appreciate above information and total overhead from Payment gateway internal processes (avg. 2-3 sec).

Tip: Store system can limit the list of cards for performing order payment by: - setting default payment document type; - using allowed cards filters (Ask Support team to create card profile(s)). Fraud control and marketing action are the main purposes for using this feature(s).

In case of payment-gateway-side card data entry scheme the following features are available:

1. standard interface Payment page. Standard pages are automatically adapted according to the browser or device window width: less then 800 pixels - mobile, more then 800 pixels - standard interface. Russian language of graphical user interface is set by default. Ask Support team to adjust others available translations (p 8.6).

2. standard iframe Payment page. Iframe page can be used only in case of SSL-certificate presence on Store web site. Default iframe page size - 700x500 pixels. Ask Support team to assign iframe page to Store shop_id.

3. Payment page(s) customization - ask our Support team to provide standard templates for changes performing. Blocks #footer, #header, css can be changed. Pictures can be added. All customized payment pages should be checked, approved, named, uploaded by Support team. To manage several customized pages opening Store system should use Showcase parameter. Order comment can be added on Payment page.

1.8 Customer notification about complied authorization

According to Payment Systems standards the Customer must be notified about complied payment. Notification responsibility can be divided among Store and Payment gateway, or laid on one the participants of this process.

Payment gateway supports the following methods of Customer notification:

1. via mail - letter will contain the mail information about successful authorization (date, merchant name, sum etc.) This method can be used only if Store system transfer description/customer/email parameter. Optionally, the format of mails and the name of mailing server can be changed according to Store business demands.

2. via browser page - successful/unsuccessful authorization data will be shown in Customer web page after payment completion. This method can be used only if card date input is performing on payment-gateway-side.

If Store decides to perform Customer notification by its own, Payment gateway can deactivate notification.

To set up one of the chosen variants Store must ask Support Team for it.

1.9 Obtaining processing status and results

Payment gateway supports the following types of Store system informing about order processing status and results:

1. push - Payment gateway call Store system service. It means that Store system must support proper notification contract, described in separate document (Notification service description). Ask Support Team for it.
2. pull - Store system call Payment gateway service. It is described in this document (p. 3). Store system decides on its own the frequency and periodicity of order status requests.

Tips: Combined variant assumes that Store system will use both push notification and pull request types. This approach is the most preferable as in case of unavailability of Store system or Payment gateway notification service, Store system can request for order status via different methods of status service or vice versa.

1.10 Obtaining payment mail notification

Optionally, Store system can receive notification results in raw, informative format by using check service:

1. push - Payment gateway services will send the copy of every generated notification letter on the email address specified by the Store. Ask Support Team to add your or your company’s assigned email address to mailing list.
2. pull - Store system can request for all or selected notification mails by using check service. Response is provided in xml format.

More information about check service can be found in separate document (Mail notification retrieve). Ask Support Team for it.

1.11 Liability levels

1. reliable - Store provide Payment gateway with data for access to goods/services management system. While processing the order payment, Payment gateway will request for availability of certain goods/services, and in case of positive response it will send request for receipt formation for future services or goods delivery.
2. not reliable - Store system independently controls order cart formation, payment status, goods/services delivery.

Note: Store system doesn’t obtain exclusive right to choose one or another Payment gateway liability level. It is approved by Store together with the Acquirer.

2. ORDER REGISTRATION:

Order registration in PG can be performed with several methods of service order. All of these methods contain basic information about the order, customer and postdata block, but differs in included functionality. The following methods are available:

1. register_simple - contains only basic parameters for order registration;
2. register_online - contains basic parameters, cart description block for reliable type of integration and recurring block of parameters for performing recurring payments. Usually is used for recurring scheme of charges.
   
3. register_offline - contains basic parameters, cart description block for reliable type of integration and allows to register orders for further offline payment. Usually is used for offline types of payments. Is described in Offline payments functional description.
4. register - contains basic parameters, cart description block for reliable type of integration, offline payments functional and block of parameters for performing combined type of payments. Usually is used for reliable type of integration, and combined type of sale.

Note: The choice of one method or another depends on the business needs of OS. Recurring payments functional, combined sales functional and reliable type of integration functional are described in separate documents. Ask Support Team for it.

Note: This document contains only register_simple request as the basic variant of request for performing order registration in PG system. If it doesn’t respond OS business needs ask Support Team to provide the certain document from aforementioned list.

In case of successful request processing by Payment gateway OS will receive data for performing Customer browser re-direct to PG secure page.

Response parameters:

Example:

    <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
    <soap-env:Body>
        <registerResponse xmlns="http://www.sirena-travel.ru">
            <retval>
                <session>c857e452e31349d7b2e9a4b1738e9453</session>
                <paycode>01112223334440</paycode>
                <redirect_url>https://sandbox.egopay.ru/payments/request</redirect_url>
            </retval>
        </registerResponse>
    </soap-env:Body>
</soap-env:Envelope>

In case if the response timeout is reached, the Store system can resend order registration request or send one of the requests of status service, get status response and then repeat order registration request.

Note: Incorrect request will lead to SOAP fault in response (p. 1.3).

If order registration is completed successfully, Payment gateway set order status to registered. When the order is registered, Payment gateway begins order processing and changes order status to in_progress. After, order status changes depends on authorization results:

1. decline - to not_authorized
2. accept - to authorized

After authorized status is obtained, Payment gateway changes over order status depends on confirmation configuration (p. 1.6):

1. auto - order status changes to acknowledged, and no manual confirmation required.
2. manual - order status changes to not_acknowledged, and order is ready to manual confirmation.

2.1 Register_simple method

Service: order

Method: register_simple

Request parameters:

Postdata value/name values:

Note: The main difference between ReturnURLOk/ReturnURLFault and ReceiptURL is that ReceiptURL parameter has no indicator of order processing status. This means that Store system should define order status itself (to display it to Customer) using Payment gateway services information.

Example:

<?xml version="1.0" encoding="utf-8"?>
<soap-env:Envelope
    xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soap-env:Body>
        <register_simple>
            <order>
                <shop_id>111</shop_id>
                <number>12345</number>
            </order>
            <cost>
                <currency>RUB</currency>
                <amount>1350</amount>
            </cost>
            <customer>
                <phone>+79859998877</phone>
                <name>Vasya Pupkin</name>
                <email>vasya@mail.ru</email>
            </customer>
            <description>
                <timelimit>2015-12-21T23:23:23</timelimit>
                <paytype>card</paytype>
            </description>
            <postdata>
                <PostEntry>
                    <name>Language</name>
                    <value>ru</value>
                </PostEntry>
                <PostEntry>
                    <name>ReturnURLOk</name>
                    <value>http://abc.ru</value>
                </PostEntry>
                <PostEntry>
                    <name>ReturnURLFault</name>
                    <value>http://abc.ru</value>
                </PostEntry>
            </postdata>
        </register_simple>
    </soap-env:Body>
</soap-env:Envelope>

3. ORDER STATUS RETRIEVE

At any time after the order was registered, Store system can retrieve order status. This functional is represented in order service and status service which include the following methods:

1. get_status
2. get_by_order
3. get_by_order_period
4. get_by_payment_period

The description of all methods can be found below.

Note: There is no difference between get_status and get_by_order methods responses. If OS system affords requesting only one service it use only get_status method of order service, if several - any of methods of status service.

3.1 Get_status method

Service: order

Method: get_status

Request parameters:

Example:

<?xml version="1.0" encoding="utf-8"?>
  <soap-env:Envelope
  xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soap-env:Body>
      <get_status>
        <order>
            <shop_id>111</shop_id>
            <number>12345</number>
        </order>
      </get_status>
    </soap-env:Body>
</soap-env:Envelope>

Response parameters:

Example:

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soap-env:Body>
        <get_statusResponse xmlns="http://www.sirena-travel.ru">
            <retval>
                <status>acknowledged</status>
                <order>
                    <shop_id>123</shop_id>
                    <number>12345</number>
                </order>
                <shopref xsi:nil="true" />
                <payments>
                    <Payment>
                        <authorg>ucs</authorg>
                        <authcode>123456</authcode>
                        <clearing>card</clearing>
                        <amount>
                            <amount>1350.00</amount>
                            <currency>RUB</currency>
                        </amount>
                        <doc>
                            <holder>Vasya Pupkin</holder>
                            <code>CA</code>
                            <number>510000*0008</number>
                        </doc>
                        <date>2016-07-27T09:46:18</date>
                        <type>card</type>
                        <id>620909280094</id>
                    </Payment>
                </payments>
                <error>
                    <category>system</category>
                    <code>ok</code>
                </error>
            </retval>
        </get_statusResponse>
    </soap-env:Body>
</soap-env:Envelope>

3.2 Get_by_order method

Service: status

Method: get_by_order

Request parameters:

Example:

<?xml version="1.0" encoding="utf-8"?>
  <soap-env:Envelope
  xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soap-env:Body>
      <get_by_order>
        <order>
            <shop_id>111</shop_id>
            <number>12345</number>
        </order>
      </get_by_order>
    </soap-env:Body>
</soap-env:Envelope>

Response parameters:

Example:

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
    <soap-env:Body>
        <get_by_orderResponse xmlns="http://www.sirena-travel.ru">
            <retval>
                <payments>
                    <Payment>
                        <amount>
                            <amount>1350.00</amount>
                            <currency>RUB</currency>
                        </amount>
                        <date>2016-07-27T09:46:18</date>
                        <clearing>card</clearing>
                        <authcode>123456</authcode>
                        <id>620909280094</id>
                        <doc>
                            <exp_date>2020-12-01T00:00:00</exp_date>
                            <code>CA</code>
                            <number>510000*0008</number>
                            <token />
                            <holder>Pupkin Vasya</holder>
                        </doc>
                        <type>card</type>
                        <authorg>ucs</authorg>
                    </Payment>
                </payments>
                <error>
                    <code>ok</code>
                    <category>system</category>
                </error>
                <order>
                    <number>12345</number>
                    <shop_id>111</shop_id>
                </order>
                <shopref />
                <status>acknowledged</status>
            </retval>
        </get_by_orderResponse>
    </soap-env:Body>
</soap-env:Envelope>

Note: Incorrect request will lead to SOAP fault in response (p. 1.3).

get_by_order_period / get_by_payment_period methods are used to get information about the orders registration or payments completion within requested timeframe respectively.

Service: status

Methods: get_by_order_period, get_by_payment_period

Request parameters:

Example:

    <?xml version="1.0" encoding="utf-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:egop="http://egopay.ru">
    <soapenv:Header/>
    <soapenv:Body>
        <egop:get_by_order_period>
             <egop:shop_id>22222</egop:shop_id>
             <egop:start>2016-01-23T10:42:00.000Z</egop:start>
             <egop:stop>2016-01-23T11:42:00.000Z</egop:stop>
        </egop:get_by_order_period>
    </soapenv:Body>
    </soapenv:Envelope>

Max period value – 2 hours.

Response parameters: include the list of orders, each of that consists of items described above in get_by_order method (see response parameters for get_by_order request).

Note: Incorrect request will lead to SOAP fault in response (p. 1.3).

All described methods of status service are used in 2 cases:

1. to retrieve orderstatus;
2. to get error code in case if no response returned on confirm/refund/reject requests.

4. ORDER CONFIRMATION:

After successful order processing, order status changes to not_acknowledged.

Method usage rules and regulations:

1. amount always must be equal or less authorized amount, else Store system will receive wrong_amount failure (p. 8.1).
2. amount may be less then authorized amount only if Store opened partial confirmation feature. Ask Support Team for it.
3. Store system may send more than one confirm request for one order, and if amount in this requests will be equal then Store system will receive positive response for every request.
4. If Store system will send confirm requests where amount will not be equal then Payment gateway will save amount of the first processed request, and for all another confirm requests with another amount Store system will receive already_processed failure (p. 8.1).

Note: In scenario when Store system did not receive response it may resend it. Payment gateway use shopref parameter (is generated for each new request by Store system) to identify is Payment gateway process this request or not. If case when Payment gateway identify that request already processed, Store system will receive already_processed failure (p. 8.1).

Service: order

Method: confirm

Request parameters:

Example:

    <?xml version="1.0" encoding="utf-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:egop="http://egopay.ru">
    <soapenv:Header />
    <soapenv:Body>
        <egop:confirm>
            <egop:order>
                <egop:shop_id>22222</egop:shop_id>
                <egop:number>123-123</egop:number>
            </egop:order>
            <egop:cost>
                <egop:currency>RUB</egop:currency>
                <egop:amount>100</egop:amount>
            </egop:cost>
            <egop:shopref>90bcdcc5-d31d-401a-b9f8-35e86c31aefe</egop:shopref>
        </egop:confirm>
    </soapenv:Body>
    </soapenv:Envelope>

Response parameters: Are the same as in p. 2 (order registration response).

Note: Incorrect request will lead to SOAP fault in response (p. 1.3).

If the confirm request is completed successfully, Payment gateway changes order status to acknowledged. In case of missed order confirmation request, Payment gateway changes order status to canceled.

When Store uses manual confirmation scheme, Payment gateway changes status of every successfully payed order to not_acknowledged. If the confirm request is completed successfully, Payment gateway changes order status to acknowledged. Depending on the chosen type of Payment gateway reaction on expiry time of confirmation awaiting, order status can be changed to:

• confirmed in case of confirm-on-expire scheme;
• cancel in case of cancel-on-expire.

5. ORDER CANCELATION

Cancel method is used to stop payment process of the order, which is already registered in Payment gateway, but isn’t paid for any reason.

Method usage rules and regulations:

1. Cancel method can be used only if order status is registered.
2. Store system may send more than one cancel request for one order. It will receive positive response for every request.
3. If Store system sends cancel requests while order status is not registered then Payment gateway will return already_processed failure (p. 8.1).

Service: order

Method: cancel

Request parameters:

Example:

    <?xml version="1.0" encoding="utf-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:egop="http://egopay.ru">
    <soapenv:Header/>
    <soapenv:Body>
        <egop:cancel>
            <egop:order>
                <egop:shop_id>22222</egop:shop_id>
                <egop:number>123-123</egop:number>
            </egop:order>
        </egop:cancel>
    </soapenv:Body>
    </soapenv:Envelope>

Response parameters: Are the same as in p. 2 (order registration response).

Note: Incorrect request will lead to SOAP fault in response (p. 1.3).

If the cancel request is completed successfully, Payment gateway changes order status to not_authorized.

6. ORDER REJECT

Reject method is used to reverse payment authorization of the order, which is already paid for in Payment gateway. Only authorized payment can be reversed.

Method usage rules and regulations:

1. Reject method can be used only if order status is not_acknowledged.
2. Store system may send more than one cancel request for one order. It will receive positive response for every request.
3. If Store system sends reject requests while order status is not not_acknowledged then Payment gateway will return already_processed failure (p. 8.1).

Service: order

Method: reject

Request parameters:

Example:

    <?xml version="1.0" encoding="utf-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:egop="http://egopay.ru">
    <soapenv:Header />
    <soapenv:Body>
        <egop:reject>
            <egop:order>
                <egop:shop_id>22222</egop:shop_id>
                <egop:number>123-123</egop:number>
            </egop:order>
        </egop:reject>
    </soapenv:Body>
    </soapenv:Envelope>

Response parameters: Are the same as in p. 2 (order registration response).

Note: Incorrect request will lead to SOAP fault in response (p. 1.3).

If the reject request is completed successfully, Payment gateway sets order status to canceled.

7. PAYMENT REFUND

The Store must use refund method to complete the payment refund (after the order was confirmed and transaction process is completed).

Method usage rules and regulations:

1. Method may be used only after order confirmation procedure complete successfully (after using confirm method with positive response or authorization in auto confirmation case).
2. amount must be equal or less then confirmed and not refunded amount, else Store system will receive wrong_amount failure (p. 8.1).
3. amount may be less then confirmed and not refunded amount only if Store opened partial refund feature. Ask Support Team for it.
4. Store system may send more than one refund request for one order, if Store opened multiple refunds feature. Ask Support Team for it.

Note: In scenario when Store system did not receive response it may resend it. Payment gateway use shopref parameter (is generated for each new request by Store system) to identify is Payment gateway process this request or not. If case when Payment gateway identify that request already processed, Store system will receive already_processed failure (p. 8.1).

Service: order

Method: refund

Request parameters:

Example: Total cost of the order is 100 RUB, 100 RUB must be refunded.

    <?xml version="1.0" encoding="utf-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:egop="http://egopay.ru">
    <soapenv:Header />
    <soapenv:Body>
        <egop:refund>
            <egop:order>
                <egop:shop_id>22222</egop:shop_id>
                <egop:number>123-123</egop:number>
            </egop:order>
            <egop:payment_id>222222111111</egop:payment_id>
            <egop:cost>
                <egop:currency>RUB</egop:currency>
                <egop:amount>100</egop:amount>
            </egop:cost>
            <egop:shopref>d7715995-85ce-4465-bb1b-64f7359e3681</egop:shopref>
        </egop:refund>
    </soapenv:Body>
    </soapenv:Envelope>

Response parameters: Are the same as in p. 2 (order registration response).

Note: Incorrect request will lead to SOAP fault in response (p. 1.3).

If the refund request is completed successfully, Payment gateway sets order status to refunded.

The Store must use refund method to complete the partial payment refund (after the order was confirmed and transaction process is completed). The Store system should correct refund/cost/amount parameter to perform partial refund.

Service: order

Method: refund

Request parameters: Are the same as for refund method.

Example: Total cost of the order is 100 RUB, 60 RUB must be refunded.

    <?xml version="1.0" encoding="utf-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:egop="http://egopay.ru">
    <soapenv:Header />
    <soapenv:Body>
        <egop:refund>
            <egop:order>
                <egop:shop_id>22222</egop:shop_id>
                <egop:number>123-123</egop:number>
            </egop:order>
            <egop:payment_id>222222111111</egop:payment_id>
            <egop:cost>
                <egop:currency>RUB</egop:currency>
                <egop:amount>60</egop:amount>
            </egop:cost>
            <egop:shopref>d7715995-85ce-4465-bb1b-64f7359e3681</egop:shopref>
        </egop:refund>
    </soapenv:Body>
    </soapenv:Envelope>

Response parameters: Are the same as in p. 2 (order registration response).

Note: Incorrect request will lead to SOAP fault in response (p. 1.3).

If the refund request is completed successfully, Payment gateway sets order status to refunded.

8. REFERENCES

8.1. REQUEST PROCESSING SOAP FAULT CODES

8.2. ORDER PROCESSING ERRORS CODES

8.3.ORDER STATUS

8.4 EVENT CODES

8.5 3DS AUTHENTICATION STATUS

8.6 User interface language

8.7 Payment session types

8.8 Card codes

8.9 Card data input modes (ChoosenPayMode)