Payment Gateway - FAQ
Currently Payments2Us is availble with:
Windcave (formally Payment Express) - https://www.windcave.com/
Stripe - https://stripe.com/au
Authorize.Net - https://www.authorize.net/
EziDebit - https://www.ezidebit.com
DataTrans - https://www.datatrans.ch/en/
If you have any queries regarding other payment gateways, please email [email protected]
Your question might also look like " I have Stripe and Paypal both option on Payment Form and I do need both to be configured both on single form but payment form only gives me the option of single webhook key. It seems that you either need to go with Stripe or with Paypal, but the solutions is to use a different payment form for each. Attached a picture of the form's section."
Whilst the webhooks are specified at the Payment Form level, they are NOT specific to that Payment Form. You can create two Payment Forms, one for Stripe, one for PayPal and enter the corresponding webhook in each respective Payment Form.
So you would specify Stripe and the Stripe Webhook Secret Key on Payment Form 1.
And specify PayPal and the PayPal Webhook Secret Key on Payment Form 2.
You can then use Stripe or PayPal as checkout options with with Payment Form.
The simplest way is to use the Create Samples from the About Payments2Us Tab. This will generate a DEMO FACILITY in the merchant facility tab and that will have a test account.
If you have created a Full or Partial Sandbox and that has included copies of your Merchant Facility, then you will first need go to the Merchant Facility Tab, then rename the DEMO FACILITY or delete it. Then use the Create Samples again from the Merchant Facility.
If you want to test using your payment gateway specific, vs. the Windcave generated one, or you wish to see the transactions in the Payment Gateways online portal, then you will need to contact the Payment Gateway directly and setup your own test account. Most Payment Gateway providers provide an online option for this, some require you to lodge a support request.
If in a newly generated sandbox, you may wish to review the Sandbox FAQ on Sandboxes.
TIP: If creating / generating a new new test/demo facility, you will most likely need to re-authorise Payments2Us.
Payments2Us integrates with a Payment Gateway. The Payment Gateway is what validates and charges a card. The success/response is recorded back in Salesforce (1).
For some gateways, such as Windcave, you need to get card types as Amex or Diners setup as a separate Merchant Facility. Contact [email protected] if using Windcave payment gateway only.
For all other Payment Gateways, you'll need to contact the payment gateway provider directly. Provide them the date/time, amount, card holder name and transaction references (2). They will be able to provide you with a reason of why the card was declined.
For customers using the Windave payment gateway:
Apart from merchants using the First Data (FDRA) Australian network, the bank specifies what will appear on the customers statements. If you would like a different name to appear on them, then you are best to contact your local bank representative. If you are transacting on the FDRA network, then you will need to inform us what you would like to appear on your cardholder's statements and also inform your bank.
When you setup your Merchant Facilities, did you get this card type included? It is normal for Visa/Mastercard to be setup and included, but you will also need a separate Merchant Facility for American Express, Diners Card etc.
If you did get this setup, did you notify payments2us.com that you wish to use this facility and provide the Merchant Info?. If not, please contact [email protected] with the details. Please note, additional Merchant Facilities do attract a once-off/one time setup fee.
Please contact your Merchant Facility provider (bank) and let them know which card types are not working.
AFTER checking with Merchant Facility provider, if have not been able to resolve then please contact [email protected]
If the issuing bank is say an overseas bank, then it could be that particular bank that is causing the issue. The card holder will need to contact the bank and ask them to resolve.
There are a series different sets of usernames:
- Payline Account - This is the Windcave portal username that can be used to view all the transactions from within Windcave via https://sec.windcave.com/pxmi3/logon
- PxPost Account - This is the account used to enter into the Payment Gateway UserID field on your Merchant Facility. Enter the password for this account in the Payment Gateway Password field. This is the connection between Salesforce and Windcave. If these credentials are incorrect the transactions will be declined.
For customers who also use PxPay (Prepay), you will also have:
- PxPay Account - This is the account used in the the PxPay/PxFusion UserID field. Enter the password for this account in the PxPay/PxFusion Password field.
Things to note:
- Each username has it's own password. They are unrealated and if any change will not change the other accounts.
- Changing of passwords for all accounts need to be manually done through Windcave. They cannot be reset within the Payline portal. If you need to reset any passwords contact Windcave via https://www.windcave.com/contact
- If you reset any passwords, everywhere that uses those credentials will need to be updated
- Payments2Us does not hold any of your passwords not has the authority to access or reset passwords.
- When contacting Windcave you will need to quote your Customer Number. If you do not have this contact [email protected] to retrieve
You can make changes to the HPP in Payline, but only the Windcave support can apply changes to live pages. So once you make your changes you will have to lodge a request to Windcave support ([email protected]) to make those updates live.
Payline is used for you can access online to your account. You can log into this https://sec.windcave.com/pxmi3/logon
Please note that this is not needed by Payments2Us . Resetting the Payline password will not have any impact on Payments2Us setup.
The way the process for the forms work is:
1. Payments2Us Checkout form (users enters details)
2. We create the Payment Txn - status of "Confirmation" - includes details entered
3. We pass over to the Windcave PxPay form
4. User enters payment details
4a. [THIS STEP SHOULD NOT HAPPEN, but is currently setup] User sees Windcave PxPay screen.
5. Windcave returns to Payments2Us checkout screen.
6. Payments2Us checks Windcave to confirm the payment details. Then updates the Payment Txn to a status of "Payment Complete"
If step 6 of this setup procedure has not been implemented, the transaction created will be in Confirmation status.
TIP: Do not close the screen/browser after step 4a: What usually happens is that the user completes steps 1, 4a and they see they have paid and all is okay, then they close the screen/browser and that stops steps 5 and 6. So, Salesforce does NOT get updated.
Solution will be to complete Step 6 in the setup link- https://help.payments2us.com/m/installation/l/824448-how-to-setup-windcave-payment-express-pxpay
The "Next" button confirms that the transaction was initiated from Payments2Us.
Multi currency only works with a Merchant Facility of NAB in Australia and BNZ in NZ.
This feature can be used with the above banks if an organization would like the customer/donor to select a different currency on the checkout form
You need to make sure your Merchant Facility (known as the Acquirer) has given permission and setup your account for ignoring recurring payment expiry dates AND they have applied those settings to your account. Should you not do this step, then you are likely to be in breach of your terms and conditions with the acquirer and the transactions are likely to fail.
Note, the ignoring of expiry dates is ONLY available for recurring billing. The initial sign up or card updates will always require and expiry date.
Once you have confirmed permission with the acquirer, then you can enable "Use Client Type - Recurring" on the Merchant Facility
When the card is updated, an Auth transaction for $0.01 is attempted. This does NOT charge the card, but reserves 1 cent. This reserve disappears after 7 days.
The card holder most likely does not have any funds left/over their limit and the transaction has failed.
Try in a few days time, or contact the card holder.
If the card still fails, ask the card holder to contact their bank to see why the funds are not being approved.
The error message is returned from the payment gateway (Windcave) and is not something generated by Payments2Us. You can try contacting their support, but extremely likely to be asked to contact the Card holder and ask them to check with their bank.
This error means the Billing Token is invalid.
The billing token is located on the Recurring Payment Object and is used to charge the Credit Card for Recurring Billing/Donations.
What may have happened is Windcave Billing Tokens often have 4 or 5 leading zeros. If you have migrated the data and used Excel, then it is likely the leading zeros were removed.
Update the Billing Token on the Recurring Payment with the Correct Token.
It is part of your contractual agreement in using Windcave to have both the logo and privacy terms shown. You therefore cannot remove these.
For CBA, after you go live, please keep an eye on the Bank Deposit date. If the Bank Deposit Date does not change from day to day, then this means CBA have missed a setup step. The below is what we've been told in the past in relation to the issue/fix that CBA needs to do:
The merchant officer mentioned that they made a change to settlement options and timing to fix issue
- (CHANGED TO) Bank Initiated, vs. Merchant Initiated.
- Windcave advised "enabling Host Settlement"
PLEASE NOTE, this is something only CBA can fix. There is nothing that Payments2Us or Windcave can change.
NOTE: Windcave is retiring the connectivity to CBA as the acquirer in 17 April 2023. You will need to get Acquiring through Windcave Directly or switch Payment Gateways.
With Windcave doing the acquiring, the funds can still settle into your bank account.
We advise acting on this early as application process can take some time. You can apply directly to Windcave at: https://sec.windcave.com/pxmi3/merchantapplicationau
Should you have further questions, please contact Windcave Support or Sales directly
This indicates an issue with the Payment Gateway. It is normally temporary and should resolve relatively quickly.
For further information, please contact Windcave Support.
Note, Windcave does offer an alert service for interuptions - please check their website or contact Windcave Support for more info or signing up.
Should Windcave service be down, you will likely get a timeout error.
You can check the status of Windcave and subscribe to outage alerts at: https://status.windcave.com/
Should you get timeout errors, we do have a process that runs 4 times a day to check the Payment Txn in Salesforce with Windcave online. It is also a good idea for you to check Payment Txns in Salesforce status vs. the Status of the payment in Windcaves online portal (PayLine)
For Windcave PxPay, the Card Numbers only show after the Captcha has been completed AND the "Next" button is pressed.
After the "Next" button is pressed, the Windcave hosted PxPay form will display and that will prompt for the card holder and card details.
JL response code means the card number associated to the token has been declined by the schemes (Visa/MasterCard) with a 'retry never' response.
The customer/card holder should present a new card to be used for billing as its been blocked by the banking system.
eChecks can take up to 6 days to clear and settle into your bank account. The Payment Txn will have a status of "eCheck Pending" until it is settled.
When the daily Recurring Payment Processor finishes, a second process is started that checks Authorize.net for transactions over the last 7 days to see if the transaction have settled successfully or not. The Payment Txn status is updated to "Payment Complete" if the transaction was successful and "Error" if it was not. The transaction check processor also updates the Payment Txn field "Settlement Date/Time" and assigns the Authorize.net Batch Id to "Payer Id" field.
For more on Authorize.net eCheck settlements, see How does the eCheck.Net settlement process work?
Please see the FAQ Above "When do eChecks's settle".
The Recurring Payment Process MUST be started, even if you are not using Recurring Payments. The Recurring Payment Processor when finished then triggers another processor that checks for eChecks being settled and will then mark the transactions as Payment Complete or Error.
See FAQ on starting batch processors (but select the one for "Recurring Payment Processor")
Payments2Us does not use, create or update the plan in EziDebit.
Payments2Us uses the "plan" / schedule on the Recurring Payment. The Recurring Payment Processor that runs each morning will generate and charge Cards/Direct Debits that are due on that day.
No, the online setup form is used to tokenise the account details and to create the Recurring Payment Schedule.
For EziDebit, the Recurring Payment is automatically marked as Active. The Recurring Payment Processor will generate a charge on the Next Payment Date.
This error occurs if the attempted charge date is more than 30 days of the Transaction date on the Payment Txn.
This error occurs when the "Payment Gateway Customer Profile Id" on the Recurring Record is blank.
The most common reason for this is the Recurring Record was created manually and the Account Details were updated manually rather than via the Update Account Details button.
To solve this,
1. Update the field with Contract Id from Ezidebit for the payee, if payee exists in Ezidebit.
2. If payee does not exist in Ezidebit then Update the Account details via Update Account Details button.
See link Section 5
(1) The Invalid digital key error is mostly associated with keys wrongly entered on the Merchant Facility.
Please make sure you have the values correctly entered as below.
1. Enter the EziDebit Supplied "Public Key" into the "Payment Gateway User Id" field
2. Enter the EziDebit Supplied "Digital Key" into the "Payment Gateway Password" field
(2) Organization Id on the Merchant Facility is incorrect. Please check if you have the correct Organization Id entered
If this does not solve the issue, you can contact Ezidebit to make sure the keys provided is for Ezidebit Production/ Ezidebit Sandbox.
(3) Your "Environment" field on the Merchant Facility is set incorrectly. For example, this should have "Production" when using live Credentials.
(4) You have entered the Username/Password for the EziDebit online portal. The digital key is different; please contact EziDebit for the Digital keys for integration.
This looks like EziDebit did not respond or came back with an error when we tried to generate a one time key for the integration.
Should this be once off or very sporadic then it can be ignored. If not, we'll need EziDebit to investigate as their servers are not responding in a timely manner or responding with incorrect information.
We maintain the Credit Card and Direct Debit schedule in Salesforce and do not use the EziDebit Inbuild recurring billing.
For Recurring Payments, we use the ProcessRealTimeTokenPayment EziDebit API for Credit Cards and the AddPaymentUnique EziDebit API for Direct Debits
Unlike Credit Cards, Direct Debits do NOT settle the same day. They may take between 3 and 7 days (or even up to 10 days in some rare instances) to settle.
After the Recurring Payment Processor is run in the early hours of the morning, a second processor is run that checks EziDebit to see if the transactions have settled. Once they do, the status is changed to Payment Complete and the normal receipting and updates processing occurs.
The EziDebitUtil.GetPayments is a process that run every morning. It runs 10 times. This is once of every one of the 10 previous days.
This error log would be an unexpected response from EziDebit. We can assume that this is a temporary issue with their servers and that it would be rectified shortly.
As the routine goes back over the last 10 days each morning, anything missed today will be picked up and corrected tomorrow morning.
If this still causes you concern, please contact EziDebit Support and provide them with the approximate date/time. Perhaps also ask to sign up to their service interruption emails.
The card update screen generally only displays the card details. Behind the scenes, we also copy information such as phone, mobile onto the Payment Txn record and use some of this as part of the card update/validation. This is required as part of the card update process.
The error means that the Recurring Payment, related Contact has an invalid Mobile Phone. Update the value in this and then try again.
The Statement Description on Card holders account comes from the Merchant Facility-> "Organisation Name" field.
Locate the Payment Txn that you are looking to have investigated, then locate:
- Payment Confirmation No.
- If the Payment Confirmation No. is blank, then use Payer Id
Login to Stripe Dashboard, then go to:
- For production: https://dashboard.stripe.com/logs
- For Test/Sandbox: https://dashboard.stripe.com/test/logs
Paste the valued (Payment Confirmation No. OR Payer Id) from above into the search box and press enter (1)
Then copy the value of the id beginning with "req_". This is what you need to send to Stripe support.
For some themes, the Expiry date and CVV can be a little light and harder to see. User will see this when entering the card details.
Should this be a concern, you can:
- Select a different "Theme" option on the Merchant Facility
- Change the Payment Gateway on the Merchant Facility to "Stripe SCA". This is the preferred option for Stripe as it uses their newer APIs
- Get your web developer to setup custom theme. Note, custom themes do have an extra monthly cost and should your web developer have questions that cannot be answered from the help guide, then you may need a Premium Support Block to assist. The advantage to this option though is your form would better match the rest of your websites branding.
For Stripe, the section highlighted below is controlled 100% by Stripe. It is hosted on their server.
There is no way to split this out or separate these fields. The Payments2Us Payment Form builder has no influence on these fields.
If you are getting an email from Stripe Saying you are getting a Webhook Failure, then check:
- Go through the Stripe setup process again. Make SURE you have used the Reveal for the secret key, vs. copying another reference shown on the page.
- Recheck all Sharing Rules have all been setup correctly. Suggested Sharing Rule setups do change from time to time.
- The Payment Txn is located by the "TxnRef" field AND Last Modified Date (Created date prior to version 9) is in the last 5 days. Probably it can occur when your admin has enabled Create Audit Fields - please get this turned off.
For Stripe SCA, the Credit Card details do not show until the "Next" button is pressed. This is due to the way Stripe SCA works and its method of managing security features such as Secure 3D.
See payment gateway comparison for an up-to-date comparison between gateway options.
The "SCA" in "Stripe SCA" stands for Strong Customer Authentication. This means it includes Secure 3D anti fraud functionality to make transactions more secure.
Any new functionality of Payments2Us will only be added to "Stripe SCA". Currently a big difference is Apple Pay and Google Pay are only available with "Stripe SCA".
One key user experience difference is "Stripe SCA" requires users to press the "Next" button before the credit card/payment details section will show.
For Stripe, all external facing forms require a CCV
When you are logged in as a Salesforce user, CCV is optional with:
Stripe does NOT provide use with the ability to just update the expiry date. That is why the message on the Card Expiry Update shows.
Some gateways do provide this. You can see a comparison at: https://help.payments2us.com/m/installation/l/1284641-what-are-the-differences-between-payment-gateways
You'll need to do a full Card Update with Stripe but using the "Card Update" button/component on the Recurring Payment Object. Alternatively send the Card Update link to the Card Holder so they can update the details.
Follow up question we some times receive: Can we update the expiry date within the Stripe Dashboard.
Unfortunately this update within Stripe will not sync back to Salesforce. For the next charge, we will still be sending the old expiry date and this will cause the payment to fail.
You'll need to use the Card Update and enter the full details from the Recurring Payment, or send the Card Update link to the Card Holder so they can update the Card Details.
Please check if the sharing rules have been setup properly. Especially check for the Recurring Payments Sharing Settings.
Note: this is applicable if the error is in the Payment Gateway Response Desc
We pass as many details as we possibly can to NAB Transact. The integration options are very limited an email is not an item that is available to us.
We do pass in the "Billing Token" field form the Payment Txn to the Transaction Reference (aka Purchase Order No.) field in NAB Transact.
All reporting should be completed from within Salesforce. This will have all the details you need, including Email address.
The use of NAB Transact login should be in the very rare circumstance of an issue between NAB Transact and Salesforce reconciling.
If NAB have asked you to review their Risk Management settings in NAB Transact and adjust them to meet the Payments2Us security and ensure the Payments2Us Risk software is compatible with the NAB Transact Risk settings, then please note:
- These settings are in addition to ours. The most restrictive of either NAB Transact settings or our settings will be used. Our settings are applied first before submitting the transactions to NAB Transact.
- We do have a number of settings that are configurable, such as the Risk and IP Management.
- Salesforce as a platform also provides a number of inbuilt security controls that we leverage.
To answer this question, the you can use the NAB Transact settings in conjunction with ours. If the NAB settings are less restrictive than PaymentsUs settings then the Payments2Us settings will apply.
Sample below of NAB Transact Risk Settings that you may be asked to confirm.