New Payments API Integration Configuration - Rushed Decisions and Timeline

To Keap,

Regarding the following announcement of the New Payments API Integration Configuration.

Upgrade to Keaps New Payments API Integration Configuration

Payments API Integration Configuration

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.

Iā€™ve submitted a support ticket, but my testing of this process revealed a few issues.
Case Number: 03456939

  1. The self closing custom tag:
<keap-payment-method 
id="keap-payment-method"  
  key="YOUR_SESSION_KEY"  
/> 

ā€¦ removes content that follows, unless that content is enclosed with in a different tag. I had to close the tag explicitly:

<keap-payment-method 
id="keap-payment-method"  
  key="YOUR_SESSION_KEY"  
></keap-payment-method>
  1. You canā€™t use a test CC number ā† maybe resolved

  2. 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.

1 Like

Marion, glad you are trying things out with this.

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.

@Pav,

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.ā€

Thanks,
Tim

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.

Hereā€™s an example of the false positive response, and it looks like the issue w/ the test CC number(s) have been resolved:

2025-02-18_15-13-02 - TechSmith Screencast - TechSmith Screencast ā† Return result is false positive {paymentMethodId: 0, success: true}

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.

@vishal_kumar when is the last time you tried this?

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 just tried it and got the same paymentMethodId = 0

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ā€™m using the Stripe payment.

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.

Thanks, update me when you will get the response.

Hi Keap,

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?

Welcome @Andrew_Pfund,

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.