How should I configure my Secure Web Pay permissions for 3DCart?
Merchants using the 3DCart integrated shopping cart with Secure Web Pay should configure SWP with the following permissions:
Permission/Field | Value | Virtual Terminal Location |
---|---|---|
Accept Unsigned Transactions? | Yes | Virtual Terminal > Gateway Settings > Secure Web Pay > Main tab > select MERCHANT > Settings section |
Return Page | https://yourdomain.3dcartstores.com/paymentreceive.asp?gw=paymentsgatewayswp | Virtual Terminal > Gateway Settings > Secure Web Pay> Main tab > select MERCHANT > Settings section > click +/- to expand or collapse return page collection (any empty return page may be used) |
Consumer Order ID | Complete the following fields:
NOTE: Click the Update button to save your changes before navigating to a different tab category. | Virtual Terminal > Gateway Settings > Secure Web Pay > Field Settings tab > select MERCHANT> Merchant Defined Fields section > check the Show Legacy Settings option |
What are some troubleshooting tips for signed SWP requests?
When troubleshooting signed SWP request messages, forward the following elements (with sensitive values like account numbers and passwords masked) to your Integration Specialist along with a description of the issue for review:
Element | Example |
---|---|
Exact URL where you're sending the SWP request message | SWP-Redirect URL: https://sandbox.paymentsgateway.net/SWP/Redirect/default.aspx |
Exact SWP request message you're sending to the URL referenced above | SWP-Redirect Request message (example with sensitive data replaced): |
Exact message string you're encrypting using an HMACMD5-compatible algorithm | SWP-Redirect message string to encrypt using HMACMD5(..) : "r2A8X5V2fj|10,20|2.0|1.00-5.00|634444442150000000|237938||insert||insert" |
Merchant ID | Merchant ID (example): 123456 |
External IP address of server submitting the SWP request message | External IP address of server submitting the SWP-Redirect request message (example): 10.100.11.101 |
Exact SWP response message when your experienced the difficulties | SWP-Redirect Response message (example): |
How can I change the Pay Now button to a link in SWP Checkout?
Secure Web Pay Checkout request parameters may be passed in the browser as part of the URL string:
Live
https://swp.paymentsgateway.net/co/default.aspx?request_parameter_1=value&request_parameter_2=value&......&request_parameter_xx=value
Sandbox
https://sandbox.paymentsgateway.net/swp/co/default.aspx?request_parameter_1=value&request_parameter_2=value&......&request_parameter_xx=value
Most Popular Usage Examples
Live
https://swp.paymentsgateway.net/co/default.aspx?pg_api_login_id=abcdefgh
Sandbox
https://sandbox.paymentsgateway.net/swp/co/default.aspx?pg_api_login_id=ijklmnop
What are SWP Checkout's Retry Policies?
When asynchronous postback failures occur within SWP Checkout 2.0, the system attempts to resend the response if the POST action did not result in an HTTP 200 response (i.e., OK). The number of retry attempts depends on the actual error (e.g., transaction error vs. an endpoint connection failure).
How do I make the reCaptcha image display using Safari when I access SWP Checkout in an embedded iframe?
If you see a white panel after selecting the "I'm not a robot" reCaptcha checkbox, you'll need to update your browser to Safari 12.1.2 or higher. Safari version 12.1.1 has issues properly displaying the reCaptcha verification when you access SWP Checkout in a nested iframe greater than 512px. If you continue to experience problems after updating your browser version, consider the following additional solutions:
- Search Google for the "512px Safari iFrame reCaptcha Workaround." The reCaptcha verification may work inside an iframe that is 512px or less.
- Inject the following header inside the iframe:
<style type="text/css">.rc-image-tile-wrapper{transition: auto !important}</style>
What are some SWP-Checkout flows?
This solution details SWP-Checkout customer experiences when the following SWP-Checkout request parameters are used:
- pg_return_url -------------> we will refer to this as the receiving endpoint for the postback
- pg_return_method
- pg_continue_url
- pg_cancel_url
Case I. ( if pg_return_method="Post" ):
Upon approval, the postback will be sent and the customer will be redirected to the receiving endpoint. Upon decline, no postback will be sent. The customer will be redirected to the endpoint specified in the 'pg_cancel_url' request parameter upon click of the 'Abort' button (shown on the Transaction Decline dialog).
Case II, ( if pg_return_method='AsyncPost' ):
Upon approval or decline, the customer will either be first displayed the receipt (upon an approval) or be displayed the Transaction Decline dialog (upon decline). Next, the postback will be sent asynchronously. Lastly, the customer be redirected to the respective endpoints specified in 'pg_continue_url' or 'pg_cancel_url' request parameters upon click of continue (shown on the receipt) or abort (shown on the Transaction Decline dialog) buttons, as appropriate.
More information on the 'pg_return_url', 'pg_return_method', 'pg_continue_url', and 'pg_cancel_url' is available in the SWP-Checkout developer documentation available here: https://www.forte.net/devdocs/pdf/SWP_Integration.pdf. We strongly encourage testing this in the sandbox test environment.