Developer Portal

• PaywayWS ACH Integration Guide
• PaywayWS Redirected Payment Form Integration Guide
• Payway User Guide
• Payway Admin Guide
• Payway ApplePay Integration Guide
• Payway GooglePay Integration Guide
• Payway Point-to-Point Encryption(P2PE) User Guide
• Payway File Processing User 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

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

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.

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.

There are two methods for capturing funds from a cardholder’s account.  The first is to authorize, which puts a hold on the account for the amount authorized, followed by a capture, which causes the held amount to be transferred to the merchant’s account.   The second method is a sale request, which is equal to an authorize and capture in a single step.

Authorize / capture is used in a fulfillment environment where the funds must be held but the sale is not finalized until the product or service is delivered.  If an Authorize is not followed by a Capture request, the hold on the funds will eventually expire, but it is strongly suggested that you execute a void against any authorization that will not be captured.

Sale is used when the charge will be made immediately, for example, when processing a recurring subscription charge.

NOTE:  If a sale is requested but the results are not available for whatever reason, do not request another sale until you request the data for the original request and inspect it to make sure it has not been captured. Otherwise double charges may occur. One way to avoid this is to make sure you create unique transaction IDs. Then, if you send the same transaction ID in, PaywayWS will reply with a duplicate notice and the status of the already-existing transaction.

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.
• testResultFSV controls the contents of the returned FraudSecurityResults field. This is used for client-side processing of FraudSecurityResults or in testing the Payway Fraud Prevention component of PaywayWS.
• testResultAVS controls the contents of the returned AddressVerificationResults. This is used to test any processing of address verification results on the client side, or in testing the setting for the Payway Fraud Prevention component of PaywayWS.

Payway provides common response results for the development and test/stage environments. Note that any account/transactions do not get transmitted to the credit network.  The responses below are returned when specific accounts are used for processing.

WARNING:  ONLY USE THE ‘paywayCode’ as the element to determine a transaction result.