GP webpay: Practical Examples

Transcription

1 : July 2013

2 TABLE OF CONTENTS: EXAMPLE 1: PURCHASE OF GOODS CREATING AN ORDER WITH AUTHORIZATION... 4 EXAMPLE 2: PURCHASE OF GOODS IMMEDIATE REQUEST FOR TRANSFERRING THE AMOUNT FROM THE CARD HOLDER S ACCOUNT... 7 EXAMPLE 3: DELIVERY OF GOODS TRANSFER OF THE AMOUNT FROM THE CARD HOLDER S ACCOUNT TO THE MERCHANT S ACCOUNT... 8 EXAMPLE 4: DELIVERY OF GOODS INCORRECTLY ENTERED AMOUNT... 9 EXAMPLE 5: ORDER CANCELLATION EXAMPLE 6: CARD HOLDER S COMPLAINTS EXAMPLE 7: CLOSING AN ORDER EXAMPLE 8: DELETING AN ORDER Global Payments Europe, s.r.o. Global Payments Europe, s.r.o., V Olšinách 80/626, Praha 10 - Strašnice Global Payments Europe, s.r.o. 2

3 PRACTICAL EXAMPLES This document describes the most frequent cases of processing orders in the GP webpay system. It does not include any strict instructions as to how to process orders. The document is only for your information and contains some recommendations on how to process orders in the GP webpay system. The document was prepared based on practical experience of GP webpay users. Global Payments Europe, s.r.o. 3

4 EXAMPLE 1: PURCHASE OF GOODS CREATING AN ORDER WITH AUTHORIZATION Creating an order with authorization i.e. blocking of the required amount on the card holder s bank account This type of payment is used when physical products are purchased. As soon as GP webpay receives an order, it sends automatically a request to authorize this order - after successful authorization the amount is blocked on the card holder s bank account. When the goods are delivered, the merchant sends an online request to DEPOSIT, or the merchant can use the instruction Payment / Deposit for the order via the administrative web interface of the GP webpay system. For details, see Delivery of goods. Procedure: 1) The card holder selects GP webpay as a method of payment on the merchant s web page; 2) The merchant redirects the card holder s Internet browser to GP webpay web pages. He/she sends a request to create an order (CREATE_ORDER) containing the parameter DEPOSIT_FLAG = 0; 3) The card holder enters sensitive data on the GP webpay web pages; 4) As the data is entered and the request is confirmed, GP webpay verifies the payment with the Directory Server of the respective association (MasterCard, VISA, DC) to find out whether 3D Secure authentication is required for the payment card used; 5) If 3D Secure authentication is required for the card holder, the card holder is redirected to the Access Control Server page of his/her bank where his/her identity is verified; 6) Depending on the result of the card holder s authentication, GP webpay continues/discontinues with the request for authorization of the order: if the card holder has been successfully authenticated, a request for authorization ensues; if the card holder has not been successfully authenticated (incorrect filling of information requested for authentication of the cardholder), it is not possible to continue. The merchant is informed about unsuccessful authentication of the card holder by sending a response to URL address given in CREATE_ORDER with relevant parameters; if the card holder s bank or the card holder do not participate in 3D Secure, system continues in order authorisation in the customer s bank. 7) Depending on the result of the authentication, an indicator is sent to the authorization centre describing the result of the card holder s authentication in 3D Secure. The indicator is one of the factors that the bank uses to either approve or decline the request for authorization. It is the responsibility of the particular banks to decide whether they accept or decline a 3D non-authenticated transaction in this step. If the bank declines the request for authorization because the card holder was not authenticated in the 3D Secure system, this information will be resent to the Global Payments Europe, s.r.o. 4

5 merchant who can display following information to the card holder: Your transaction was declined due to the impossibility of authentication of the card holder in 3D Secure. Ask your issuer bank to make this service available to you. 8) The merchant is notified about the result of authorization in the form of calling out the URL address given in CREATE_ORDER with relevant parameters that confirm success or indicate causes of failure; 9) The processing ends in this step, unless the card holder has stopped entering data in any of the previous steps. In this case, it cannot be guaranteed that the merchant s URL address is called out with the parameters describing the result. In this case, the result has to be verified by sending a request QUERY_ORDER_STATE with the order number or by checking the order status in the GP administrative web interface; 10) If the request is successfully authorized but the merchant has not delivered or will not deliver the goods to the buyer, a request APPROVE_REVERSAL must be sent to unblock the amount on the card holder s bank account. If the merchant does not send the request, the amount will be blocked on the card holder s account for the period specified by the card holder s bank. It will be unblocked automatically upon expiry of this period; 11) When the URL address is called out, the merchant informs the card holder of the result; 12) Based on the previous procedure, an order (ORDER) is created in GP webpay. The Unique order identifier is the ORDER_NUMBER field. The order may be in any of the following statuses: Requested The order has been initialized. It will remain in this status until the card holder enters sensitive data and ends the communication; Pending The order is in this status after a request is sent to the 3D Directory Server of the respective financial association; Created The order is in this status after a positive response is received from the 3D Directory Server. Then the order is authorized; Declined The order is in this status if a negative response is received from the 3D Directory Server. The order authorization cannot continue; Approved - The order is in this status if the authorization has been successful; Unapproved The order is in this status if the authorization has not been successful. 13) When the order status is verified by sending a QUERY_ORDER_STATE request, it may take some time until a response is delivered due to the interaction between the 3D systems and the authorization centre. There are also some other factors that may cause a delay and that cannot be influenced, it is necessary to bear in mind: Entering sensitive data by the card holder on GP webpay web pages; Entering card holder s identification data on the 3D Secure Access Control Server; 14) Calling out of the merchant s URL address with the result of the CREATE_ORDER request is also delayed from the same reasons as those mentioned in para 13) above; 15) It is useless to send the QUERY_ORDER_STATE request immediately after the card holder is redirected to GP webpay. It can be asserted for certain that after passing of 60 minutes since the card holder was redirected to GP webpay, the card holder has Global Payments Europe, s.r.o. 5

6 finished all the communication and the order status is final after this period. The same applies to the verification of the order status using the web graphical user interface. Global Payments Europe, s.r.o. 6

7 EXAMPLE 2: PURCHASE OF GOODS IMMEDIATE REQUEST FOR TRANSFERRING THE AMOUNT FROM THE CARD HOLDER S ACCOUNT This type of transaction is used when products are purchased and delivered immediately distribution of files, insurance, registration, etc. The merchant sends a request to create a new order (CREATE_ORDER) with the DEPOSIT_FLAG parameter set to 1. Example 2 is quite similar to Example 1, except for Step 10. If the procedure does not end with the calling out of the merchant s URL address showing the result of the processing, there may have been an error caused by difficulties in the Internet communication. The order may have been processed correctly. With regard to the DEPOSIT_FLAG value, the authorization of the order has been followed by a request for clearing of the order. The order is in the Deposited_batch_open status and at the successive entering into accounts the request to transfer the amount from the card holder s account to the merchant s account will be sent. If the merchant has not received any message about the result and has not delivered the product, the order status has to be verified by sending the QUERY_ORDER_STATUS request. If the order is in the Deposited_batch_open status the DEPOSIT_REVERSAL request (for details, see Example 4) has to be sent to cancel the accounting for the order, followed by the APPROVE_REVERSAL request (for details, see Example 5) to unblock the amount on the card holder s account. If the batch containing the transaction has been closed (and accounted for) in the meantime, a CREDIT request (for details, see Example 6) can be sent to transfer the money back from the merchant s account to the card holder s account. Global Payments Europe, s.r.o. 7

8 EXAMPLE 3: DELIVERY OF GOODS TRANSFER OF THE AMOUNT FROM THE CARD HOLDER S ACCOUNT TO THE MERCHANT S ACCOUNT This is the case when the customer has ordered goods from the merchant and the steps described in Example 1 have been successfully completed. The order is in the Approved status (authorized). The merchant delivers desired goods to the customer and therefore sends a request to transfer the amount blocked in his/her favour on the customer s bank account to his/her account. Procedure: 1) The merchant sends a deposit() request to the GP webpay Web Services interface or chooses the instruction "Deposit" for the order via the administrative web interface; 2) A payment transaction is created for the order. The payment transaction is a part of the merchant s batch. The order status changes to Deposited_batch_open. At the end of the day, all open batches of all merchants are automatically closed; 3) Transactions contained in a batch are entered into accounts once in a day. All batches that are closed at the moment of creating the export file, but that have not been entered into accounts yet, are part of the data export, which is subsequently entered into accounts by the bank. The merchant cannot influence the time when transactions are entered into accounts (time, yes/no, etc.). This is an automatic procedure; 4) When the batch containing the order is closed, the order status changes to Deposited_batch_closed; 5) Closing the batch is the standard ending of most purchases. No other action is required from the merchant. Global Payments Europe, s.r.o. 8

9 EXAMPLE 4: AMOUNT DELIVERY OF GOODS INCORRECTLY ENTERED If the merchant s administrator in charge of the GP webpay interface finds out that a payment (see Example 2) has been entered incorrectly either due to the selection of an incorrect order or due to entering an incorrect amount, he/she can correct the error. Procedure: 1) If the error is discovered before the batch is closed and the order is still in the Deposited_batch_open status, a DEPOSIT_REVERSAL request can be sent or Deposit Reversal can be selected via the administrative web interface. The order status returns to Approved. Then a new DEPOSIT request can be sent or the instruction Deposit" can be selected via the administrative web interface; 2) If the batch containing the order has already been closed and the order is in the Deposited_batch_closed status, the payment can no longer be reversed. If it is requested to return the amount to the card holder, a CREDIT request can be sent or the instruction Credit can be selected via the administrative web interface. Global Payments Europe, s.r.o. 9

10 EXAMPLE 5: ORDER CANCELLATION After the card holder purchased goods on the merchant s web pages (Example 1), he/she was authenticated successfully in the 3D systems and the result of the authorization was positive, the order is in the Approved status (Authorized). As long as the order is in this status, the customer may ask the merchant to cancel the order, or the merchant may decide not to deliver goods (e.g. goods will not be available for delivery in future). The merchant s administrator in charge of GP webpay sends the method approvereversal() to the GP webpay Web Services interface or selects the instruction Approve reversal for the respective order via the administrative web interface. The order status changes to Approve reversed", i.e. Authorization reversed. No further authorization is possible for this order. Global Payments Europe, s.r.o. 10

11 EXAMPLE 6: CARD HOLDER S COMPLAINTS The customer has made a successful complaint about a product or a service, and the merchant requests a transfer of the money in the original amount (or reduced amount) back to the card holder s account. With regard to the fact that the order has been paid already, the order reversal cannot be used. In this case, the merchant s administrator sends the method credit() to GP webpay Web Services interface or enters the instruction Credit" via the administrative web interface for the order, which is in the Deposited_batch_closed status. To enter the refund, the administrator enters the amount to be refunded. This amount must not exceed the amount originally paid. More than one refund can be created for one order. However, the sum of the refunds must not exceed the amount originally paid. If the refund has been entered incorrectly, the merchant s administrator can send the method creditreversal() to GP webpay Web Services interface or enters the instruction CREDIT_REVERSAL" via the administrative web interface for the order. If at least one reversal exists for the order in an open batch, the order is in the Credited_batch_open status. If all reversals for the order are in closed batches the order is in the Credited_batch_closed status. Global Payments Europe, s.r.o. 11

12 EXAMPLE 7: CLOSING AN ORDER If the merchant does not expect any more changes in the order and considers the order to be closed, the merchant s administrator can send the method closeorder() to GP webpay Web Services interface or enters the instruction CLOSE_ORDER" or Closing of the order via the administrative web interface for the given order. The order status changes to Closed. The only operation allowed for a closed order is DELETE, i.e. deletion of the order. Global Payments Europe, s.r.o. 12

13 EXAMPLE 8: DELETING AN ORDER If the order is in the Closed / Declined / Unapproved / Approve_reversed status and the merchant wants to delete it (that is, the order will no longer be displayed), the merchant s administrator can send the method delete() to GP webpay Web Services interface or enters the instruction Delete" or Remove via the administrative web interface for the given order. The order status changes to Deleted. The order will no longer be displayed but it will still be stored in the system for the purpose of accounting. Its unique ORDER_NUMBER identifier cannot be used for another order. Global Payments Europe, s.r.o. 13