Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

A typical sequence might look like this.

 

The SOAP header


Each server to server SOAP call to PayU's API will require a SOAP header with a username and password defined. The SOAP header serves to provide an extra layer of security forto the merchant's transaction.
An example of a PayU SOAP header XML is:

<wsse:Security SOAP-ENV:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> 
    <wsse:UsernameToken wsu:Id="UsernameToken-9" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> 
        <wsse:Username>PayU provided SOAP username</wsse:Username> 
        <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">PayU provided SOAP password</wsse:Password> 
    </wsse:UsernameToken> 
</wsse:Security>

 

setTransaction API Call


The setTransaction API call is used setup/initiate transactions between the merchant and PayU using server to server requests before paying on the PayU payment page. In doing this minimal detail about a transaction goes over HTTP POST or GET requests.

After doing a successful setTransaction request, a PayU reference number is issued in response. This reference number is used to do the payment against when the customer's browser redirects to PayU's payment page. Append this parameter and its value need to the the RPP URL and the customer's browser redirect the customer to the URL e.g.:
https://secure.payu.co.za/rpp.do?PayUReference=123456789

- Transaction Types
The transaction type parameter in the setTransaction call is used to identify what type of transaction will be done.
All transaction type parameter values as listed in the pack's included file, PayU Advanced RPP V1.x.pdf, but two are typically used - PAYMENT or RESERVE. Each of these transaction types has a different effect transaction's authorisation and settle components, which are explained below.

RESERVE transaction type
This transaction type is typically used when a merchant issues shippable goods or get stock from a supplier.

Scenario:
Once a customer does a successful payment on the PayU interface, the funds are authorised. The merchant will try and source the goods from its supplier. Once the merchant has received the stock and ready to ship, the merchant will issue a settle on the funds and ship the goods.

A typical payment sequence for the RESERVE transaction type:
1. Do a setTransaction SOAP call against PayU API on merchant's website
2. Redirect to the PayU payment interface
3. Customer submits and gets redirected back to merchant's website
4. Do a getTransaction SOAP call against PayU API on merchant's website to get transaction payment details e.g. funds successfully reserved successful
The following is typically done once the merchant is in possession of the shippable goods
5. Do a doTransaction with a FINALIZE transaction type SOAP call against PayU API on merchant's website
6. Do a getTransaction SOAP call against PayU API on merchant's website to get transaction payment details e.g. funds successfully reserved

 

PAYMENT transaction type
The PAYMENT transaction type is typically used in transactions when stock is immediately available e.g. an mp3 download or online tickets.
Scenario:
Once a customer does a successful payment on the PayU interface, the funds are authorised and settled. The merchant now gives the customer access to the goods e.g. mp3 download link

A typical payment sequence for the PAYMENT transaction type:
1. Do a setTransaction SOAP call against PayU API on merchant's website
2. Redirect to the PayU payment interface
3. Customer submits and gets redirected back to merchant's website
4. Do a getTransaction SOAP call against PayU API on merchant's website to get transaction payment details e.g. funds successfully reserved successful

 

getTransaction API Call


The getTransaction SOAP call is typically used to retrieve information on the state of the transaction for the specified PayU reference number using server to server requests between the merchant website and PayU. In doing this minimal detail about a transaction goes over HTTP POST or GET request methods. This call is typically done on the merchant website after the redirect back from the PayU payment page to find out if the customer's payment was successful or not.

More technical detail for the getTransaction call is provided in the pack's included file, PayU Advanced RPP Vx.x.pdf.

 

doTransaction API Call


The doTransaction SOAP call is used to action a type of transaction defined by the value in the transaction type parameter against a specified the PayU reference number.
If the setTransaction call sent through a transaction type that requires a follow up (RESERVE → FINALISE) then a doTransaction call needs to be done in order to complete the transaction.
Additionally, a doTransaction call can be done in order to CREDIT a PAYMENT done in the setTransaction.

In the case of a doTransaction for a FINALIZE. The transaction will go almost immediately from the NEW state to PROCESSING when PayU go off to the payment gateway to perform the payment. Upon receiving the response from the payment gateway the state is changed to SUCCESSFUL or FAILED.

1. Customer selects to pay with PayU on merchant website.

Merchant can integrate a PayU payment button which will initiate transaction with PayU.

 

2. Merchant starts the PayU process with a setTransaction request.

This is the first server-side web service call made by merchant webserver to PayU in order to set up the transaction on PayU.

 

3. PayU response: Transaction ID.

PayU will respond to a setTransaction request with a PayUReference which can then be used to redirect the customer to make a payment.

 

4. Merchant returns redirect instructions to customer browser.

The merchant has to return the redirect instructions to the browser in order to redirect the customer to PayU.

 

5. Customer browser redirected to PayU.

An HTTPS GET will be used to redirect the customer to PayU with the PayUReference. PayU will identify the transaction using the PayUReference and pick up the previous set of values passed in the setTransaction call.

 

6. Customer completes transaction on PayU.

The customer will proceed to complete the transaction on PayU by using one of the payment methods provided.

 

7. Instant Payment Notification (IPN)

If the notificationURL is populated, an instant payment notification will be sent to the merchant to immediately inform them of the result of the transaction.

 

8. PayU returns redirect instructions to the customer's browser.

After the customer has confirmed their payment, PayU will return redirect instructions to the customer's browser.

 

9. PayU redirects customer browser back to merchant website.

An HTTPS GET will redirect the customer back to the merchant's website.

 

10. Merchant requests Transaction Result (getTransaction).

The merchant issues a server-side web service call to PayU to retrieve the transaction result and determine transaction outcome.

 

11. PayU response: Transaction Result

PayU will return all payment transaction information in the response. Success or failure and other details.

 

12. Merchant Displays Success/Failure page on website

The merchant should now redirect the user to the relevant success/failure/invoice page on their own site.

 

 

  • No labels