Developer Portal

• PaywayWS Credit Card Integration Guide
• PaywayWS Redirected Payment Form Integration Guide
• Payway Users Guide
• Payway Admin Guide
• Payway ApplePay Integration Guide
• Payway GooglePay Integration Guide
• Payway Point-to-Point Encryption(P2PE) User’s Guide
• Payway File Processing Users Guide

The RESTful application name is PaywayWS. The hosted sites are listed below:

Development Server: https://paywaywsdev.com
Staging Server: https://paywaywstest.com
Production Server: https://paywayws.com

For example, to process a payment transaction on the development system the URL would be: https://paywaywsdev.com/PaywayWS/Payment/ACH.

The following table describes each of the RESTful resources supported by PaywayWS. The PATH column gives the path of the resource.  The host specification and application name are not shown in the table.

An ACH transaction differs from a credit card transaction in that the request is actually processed with the nightly batches, and there is no guarantee of funds being available.  With a credit card authorization that is not the case; funds are guaranteed when the payment is authorized.   Think of an ACH request and electronically cashing a customer’s check.  However, because you avoid the credit card payment infrastructure, your costs for an ACH payment are a tiny fraction of what the same credit card transaction would be.

Background Requests are requests that originate on your server directly to PaywayWS. Generally, these are recurring transactions where you already have a Payway account token. A common use case for background requests is to execute a batch of Payway account token-based recurring payments. It is possible to do a background request with full card data, but there are PCI validation ramifications to this.

Interactive requests are used when a web user is involved in processing a transaction, for example purchasing a good or service from your web site.  Interactive requests are always done in three steps, queue the request, send the request, and process the results. Requests are queued from your server. Then, when the user submits the payment on the browser, a java script is called to send the previously-queued request. The result code is then posted to your server for processing. Optionally you can query transaction details when the result code is returned. This pattern is followed for the implementation of Hosted Payment Entry, Hosted Account Entry, and all of the wallets (ApplePay, GooglePay, etc.).

The following diagram shows the interactive (web) request pattern in general.

For both interactive and background requests, a Payway account token is returned in the final result. This may be a new token referring to a newly-created account, or a pre-existing token. These account tokens can be stored and used for any request related to the account that is referred to by the token.
There is no need to add an account explicitly using addAccount to generate a token. If you send a sale or other type of request with account data, a token referring to the new account—possibly an existing account if all the account data matches an existing account is returned in the detailed results.

Generate a test suite for your integration. PaywayWS provides a method to generate any of the PaywayWS error codes, and also to manage fraud security results, as well as address verification results.

The cardTransaction JSON object supports three request fields for testing various error conditions:

• testResultCode determines the reply code that will be returned from the test transaction. The reply code must be one of the values listed in Appendix I. If not, the return code will be 6000, PaywayWS internal error. If there is another actual error, such as account expired, this may override your requested return status.