I don't understand how Westpac Payway API and NET works

Been googling all day, reading numerous PDF's and still getting confused with the concepts of sending data to Payway system from Westpac (a bank in Australia). They offer access via API but also give access via w开发者_开发百科hat they call "NET."

The way I understand is that when client want to pay on my website, in case of NET, client gets to the page (hosted by a bank or hosted by me) where is provided with form to enter credit card info details. Then this form is submitted via normal POST call to Payway's specific https address. It is processed then and browser returns to the URL I specified as one of the parameters I sent in hidden field.

In case of API story is similar, so user receives form, fills in the data and then data is send to my backend (not Payway's). My backend then calls payway API with data provided and once answer received returns confirmation page to the client.

Is my understanding right? Please explain as I have a feeling I am missing something basic here.

There are a number of different ways to interact with PayWay Net, depending on how much control you want. The simpliest way is this:

1. You create a HTML format containing fields with certain names. This form is served up by your website, but when submitted goes to the PayWay website. You can add to this your own hidden fields and information fields.
2. Your user enters some details and clicks Submit.
3. Your user's browser submits the form to PayWay. PayWay validates the values and displays a page asking for credit card information (over https)
4. The user enters the credit card details then confirms the transaction.
5. PayWay processes the credit card transaction
6. Optionally, PayWay can conduct a post back to your server indicating the status of the transaction so you can complete the order (called server-to-server payment notification)
7. Optionally, PayWay can redirect the browser back to your server (but do not use this to update yoru database)

There are also ways to fully customise the credit card input page and receipt page.

PayWay API is different. You install a piece of software on your server. When you want to conduct a credit card transaction, you invoke this piece of software. It talks over the internet to the PayWay server, conducts a transaction, and gives you a response. You could use this if you were writing a phone payments system, for example, as no browser is involved in the PayWay interface.

(Disclaimer: I work for Qvalent, developers of PayWay).

Your understanding is correct.

I've done a couple of Payway integrations and have always opted for the API solution so that users get a consistent experience and are not jumping between websites.

An odd thing about PayWay, is that while most payment gateways have 2 options.. a merchant hosted or server hosted, PayWay offers this pseudo-merchant hosted with their NET option using the token request. Credit Card details are taken directly on the merchant site and only redirects the confirmation momentarily to the server and then back. This would be great if a payway account worked universally with both NET and API.. but it seems an API account doesn't support NET methods. So if you want to accept cards on your site, the NET token method is pretty much eclipsed by its bigger API brother.