The SOAP header
...
<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
...
- 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 The following is typically done once the merchant is in possession of the shippable goods |
|---|
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: |
|---|
getTransaction API Call
...
More technical detail for the getTransaction call is provided in the pack's included file, PayU Advanced RPP Vx.x.pdf.
doTransaction API Call
...
Please note:
The sequence set out in this document (as well as above), is only for a golden path integration and more test cases as well as recommendations are given in the test overview section. This summarised payment sequence can change and is dependent on the transaction type used in the setTransaction call.
A typical sequence might look like this.
| Page Tree | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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.