Clarification Needed on Westpac Payway API and NET Functionality

I have been searching for information and reviewing various documents but remain perplexed about how data transmission works with the Payway system from Westpac, a bank in Australia. They offer integration through both an API and a service referred to as ‘NET.’

From my understanding, when a customer wishes to make a payment on my website, the NET method allows the customer to access a page—either hosted by the bank or by myself—where they can enter their credit card information. This form is submitted using a regular POST request to a designated Payway HTTPS endpoint. After processing, the user is redirected to the URL I specified in a hidden input field.

Conversely, with the API option, the user fills out a form on my site, and their data is sent to my server instead of Payway’s. My server then communicates with the Payway API using the provided information, and upon receiving a response, it sends a confirmation page back to the client.

Am I correctly interpreting this process? I’d appreciate a detailed explanation as I feel I might be overlooking something fundamental.

Your understanding seems largely correct in terms of the basic operation of both methods. With NET, the external server (often referred to as hosted solution) deals with the heavy lifting regarding PCI DSS compliance since card details are directly handled by Payway, offering a higher level of security directly managed by the bank.

On the other hand, the API approach gives you more flexibility to brand the user experience within your site, but it obliges you to implement stricter security measures yourself. Ensure your server is fully compliant as you’re handling sensitive information before it reaches Payway’s API. If security isn’t airtight, this could pose significant risks.

I have used the Payway system myself in various projects. One thing to keep in mind with the NET method is its simplicity and ease of use. It usually involves less backend work since you’re redirecting users to Payway’s secure payment page. This can save you resources as they handle much of the security. However, if you’re using the API method, aside from security concerns, be sure to optimize the communication between your server and the API. Network latency or downtime could affect user experience, so robust error handling is crucial.

Hey Finn, your explanation mostly aligns with my experience as well. One thing to note is that using the API can offer quicker checkout processes if integrated well, since users stay on your site, making it seamless. However, always remember to stay updated with Payway’s documentation, as they can introduce changes.

It’s great that you’re looking into the nuances of both methods. One point to consider, especially with the NET method, is its minimal impact on your site’s load and performance because all processing is done on Westpac’s servers. This minimizes your server’s load, freeing up resources for other tasks. In contrast, with the API approach, while it offers better integration and control over user experience, it requires careful monitoring of transaction flows and load balancing to prevent any bottlenecks. Always evaluate both methods in context to what fits your business needs better.