I understand the company requirements to be PCI complaint, but your timeline to make developers to make changes within 6 weeks is too much of a rush. There is going to be 15+ years worth of custom development that may not be straight forward to change for some of your customers.
In the Configuration documentation it mentions that the Contact ID is required for the āSTEP 1: Retrieve a session key to render the componentā. That decision is assuming the Contact is already known in the first place. But if a New Customer orders something for the first time, they will not exist in the Keap Account. So how can the the Payment section appear if there is No Contact ID?
Some Order Forms may just sit on a single page, so the Payment Component cannot be rendered until the Contact has been processed and the Session Key has been produced. This means it will cause more work for the developer to deal with this. For multi page Order Forms then the changes may be straight forward.
In other Payment Gateway Platforms that I have seen, you send the Card Details to an API Endpoint, in which you get a Token back. That Token can be used to send back to the Server. That should have been provided as an additional option, but the API Endpoints would have need to be updated for it.
These changes will affect integrations based in America and outside of Europe. In Europe, 3DS / SCA has been in operation for a few years, but Keap API cannot deal with the authentication part, so alternatives like Stripe had to be used instead. Does the Keap JavaScript package now handle the Authentication part, as there is no mention of it?
It feels like some of the decisions that has been made have been rushed.
You canāt use a test CC number ā maybe resolved
After I submitted the form, I got back a success message, with the paymentMethodId of 0 (zero)ā¦ which wasnāt successful, and when I checked the contact in my sandbox, the card data wasnāt there either, so if the paymentMethodId is 0 (zero) then it should be a failure.
ā¦ and moments ago trying to test the process with a client my anti-virus software blocked access to the test page because it detected the new JS bundle as potentially malicious. I updated my case w/ this new information, but something to be aware of.
What should have been provided is the ability to easily test it out. But you will need to set up a Sandbox Account to a particular Payment Gateway with the Test Mode enabled.
There is no mentioning about the Authentication part in the Documentation, so does it come up with a popup box or not? Will it work for Keap Customers that are using a European based Bank Account?
I just checked the JS file on my side and my Anti-Virus software blocked it as well.
I saw this and do not know what Keap considers āShortā, but I recommend reaching out and getting on the list to give you a bit more time:
āIf you need a short extension, please reach out to payments@keap.com no later than February 20th, 2025 . Note that extensions are not guaranteed and will only be granted for a small group based on payment volume per vendor.ā
My Keap sandbox account is using an Authorize.net sandbox account. The form loaded by the new JS bundle is preventing the use of the test card number and returns the field as āInvalidā and wonāt allow the form to be submitted.
It would be nice to pass a param in the custom tag to allow testing with CC numbers.
Keap has replied to my support ticket regarding the false positive on the paymentMethodId of 0 (zero), and I am going to assume that the response I received was miscommunicated, and I will wait to update this thread until support can clarify the situation.
Update:
Keap replied to my ticket and partially addressed the issue. The JS bundle now produces a useable paymentMethodId, however youāll need to handle the state of the submit button, because currently youāll get back a new paymentMethodId for each time itās clicked for the same card data:
I have created the custom order form using Infusionsoft ISDK in PHP. Iām using the function $app->validateCard($card);
Please let me know how I can use the new payment configuration. Iām not sure about it.
I have checked the new payment configuration but getting the paymentMethodId = 0 and success true. Please check the screenshot.
I was working with support on Friday (2/21) and they resolved it. The issue is was that Keap is pushing creating a record in the CIM and in my case because there was a duplicate, I was getting this same result.
Theyāve since resolved this issue and I was able to get back a valid paymentMethodId, and I could check the contact record in Keap and confirm it had been created on the contact.
I would open a ticket with support then. The fix may need to be applied to each tenant application.
They gave me this as the initial cause:
āE00039 error from Authorize.net: Failed to create token for Authorize.NET: A duplicate record already exists. (E00039).ā
ā¦ I wonāt get on my soapbox about this, but in short, if youāre using Authroize.net and you have the CIM enabled, youāre getting that error because thereās a profile in your CIM already and Keap is trying to create a duplicate, and youāre getting the false positive.
If youāre not using Authorize.net, you may have a similar situation if itās an Authorize.net reseller/affiliate.
I would definitely open a support ticket then. I would guess itās a similar issue where the custom already exists within Stripe and theyāre sending back the wrong data just like they did w/ the CIM record for Authorize.net.
Iām just getting back to setting this up on several apps where we currently use API methods to add credit cards. I initially tried to set this up in January but encountered nothing but errors. It took 2ā3 weeks to get those resolved and to be notified that the issue was fixed. It seems like there are still minor issues that need to be addressed.
Keap, why are you pushing a deadline for all your customers who process payments via the API with less than a month to implement custom development work for a new system that barely seems to be working as designed? Collecting payments is the lifeblood of a small business, and Iām sure many users arenāt even aware that this is going to be turned off.
In our case, Iām now forced to use credit card inputs that donāt match the theme and design of our current checkout process, which will likely affect conversion rates since we canāt update the overall design of the iframe. Will there be an option to control the design of the card fields?
Additionally, there are issues when using your code inside other JS libraries like Vue.js and React. Developers have to parse out the iframe instead of using the JS code you provide. It would be helpful if these options were explicitly mentioned in the documentation since, essentially, all thatās needed is to display an iframe with the URL: Powered by Keap additional code isnāt necessary.
Iāll report back if I run into any more issues.
Thanks to all the other devs on this thread who are working through the issues and getting them resolved!
Posting here as Iām also in the process of testing the payment method script in an effort to come up with a solution that will work with my companyās order placement flow. Iām testing in a React app and, after some struggle, I was able to get the form to render and submit but Iām getting the āthere was a problem saving the payment methodā response for both test cards and real ones. Thereās no way to tell if this is an issue with our Keap instance using Authorize.net for credit card validation or if itās an error related to trying to make this work within a React application.
Some support for or evidence of a working solution thatās compatible with popular frameworks would be a bare minimum ask for an update like this. Can we expect that to be provided before the deadline?
How strict do you have address verification? The payment form doesnāt include the address, only country and postal code. Depending on your AVS settings they may be too strict since you canāt pass the full data set.
You could test this in a sandbox account and turn off AVS.
I can verify that today, I was able to complete my model in a two step process to capture the contact info, return the session and generate the payment fields, and with the returned payment method place an order. I am using Authorize.net (sandbox), but I am not using React.
Can anyone confirm what extensions or add ons have successfully made this update?
It would help if a list of providers that have successfully made this update for Keap users and partners. From what it sounds like here, has anyone been able to successfully update their app with this?
Not sure what is going on with Keap, but they have not been engaging with the Integration Community lately.
You have raised a good point there. When the Legacy API Key announcement was made, the third party providers were not contacted until several weeks later. But this decision to make the changes so quickly, may catch some providers out.
The problem with this change requires a Session Key to be generated against a Contact ID. If providers have created Single Step Order Forms, similar to Keapās native Order Form, then they have to alter them into something else like a Two Step Order Form. That will require more work on their side, and may not have the necessary time to do all the changes given the tight timeframe. There is now only 2 weeks to go.
