@Marion_Dorsett2 Have you had success in submitting support tickets to Keap? Create a Support Ticket - Keap Developer Portal
It says no case id specified after I submit and then no tickets found.
Yes, Iāve submitted a few, the two most recently both reference this new payments javascript method.
So a few important updates as weāve heard back from support and dev. A few things theyāre working on - and further down - a number of major breaking changes if you use multiple merchant accounts.
- The HTTP 500 Internal Server Errors that sometimes come back are a known bug. Same with the āThere was a problem saving the payment methodā errors. Theyāre working on that. They expect to deploy fixes in the coming weeks.
- Form validation is going to be improved in coming weeks, too (i.e. not allowing expiration dates in the past, etc)
Alright. Now onto the breaking change. If you have multiple merchant accounts, this entire billing widget is NOT going to work well for you. For a few important reasons that are known issues and will NOT be fixed. (If you just use Keap Pay, or Stripe, or one merchant account, this wonāt impact you, and you can ignore the rest of this)
- First, this billing widget will ONLY work with your ādefaultā merchant account and not any others you have configured.
- You do NOT and WILL not have the ability to specify a merchant account ID in the session key or in the billing widget. They have very intentionally decided not to support this.
- Cards added with this billing widget are saved directly to the gateway and no longer in Keap. That means that a card saved on this default merchant account can NOT be used on any other merchant account.
- If you have multiple product lines or brands and your customers use this widget to update their card, it will ONLY update it one the default merchant account and they will have NO WAY to use this widget to update their billing for your other accounts AND you wonāt be able to run charges for those other products using the card they added for first one. This makes this billing widget only useful for businesses using one merchant account.
If you process payments across multiple merchant accounts in Keap, this billing widget will NOT be a good solution for you.
Iāll admit Iām confused on their response.
All this iframe does is capture the payment information, which is should be storing on the contact record, and then returns a payment method id.
I use the payment method id to create the order based on the data I pass via the API, and I charge the returned payment Id.
When I use the placeOrder() method it will use the default merchant.
When I use blankOrder() and I add the order items, and then run chargeInvoice(), I can tell it which merchant ID as well.
So it sounds like theyāre going to deprecate more of the XMLRPC API than they stated in the announcementā¦ which is going to break a lot more code.
@Marion_Dorsett2 the iframe is submitting the information direct to the process and it is specifically NOT being stored in Keap. Thatās why (as discussed on this thread) the entire form is different depending on the processor.
All Keap is getting back is a processorās internal card ID which is a reference to the processor stored card. And since the processor is storing the card, Keap can only request that the processor with the card charge that card. No other merchant account can use it.
You can continue to pass the payment method ID in when you charge an order, butā¦ if the card isnāt available for that processorā¦ it wonāt work. Not sure what error Keap will throw back, but Iām guessing the processor will have an error like ācard not foundā or something.
So this isnāt just about them breaking existing code - which this already does - itās also about them breaking entire business processes.
So an important update from Keap as of last evening. Theyāve āpivoting.ā
This Javascript billing widget will only be required if you are using Keap Pay in your app. And the deadline for implementation has been pushed to April 30.
If your application does NOT have Keap Pay enabledā¦ you donāt need to make any changes at this time, at least not until after April 30th, details/timelines TBD.
This will be officially announced at some point soon.
Thanks for the update Jeremy.
We did end up running into a last minute snag, as it seems Keap is having trouble charging the cards (via API) we add through the widget when using Keap Pay. Cards added via API previously worked fine. Weāll have to add a support ticket for that.
It definitely does not seem that the widget is ready for production at this time.
Thursday (3/30/2025) I was working with a client to start the implementation process, and the Authorize.net bug returned returning the false positive because the payment method already exists in the CIM profile.
{
paymentMethodId: 0,
success: true
}
Iāve submitted another ticket this morning regarding this issue.. weāll see if they fix it.
Keap is now returning two warnings, when the snippet they documented here:
is defined the way they are asking to define it on a page:
<keap-payment-method id="keap-payment-method" key="YOUR_SESSION_KEY"></keap-payment-method>
The warnings are:
[Keap Payments] Warning: Using key attribute is deprecated. Use data-key attribute.
[Keap Payments] Warning: Id attribute is no longer required.
I changed the HTML to:
<keap-payment-method class="keap-payment-method" data-key="YOUR_SESSION_KEY"></keap-payment-method>
and the warnings disappeared.
I donāt think a warning when an ID is used is necessary. Rather, the documentation should be updated, and that should be communicated to the community, instead of making us aware of updates through warnings and errors in the console.
I saw these warnings today as well while I was testing other issues.
Throwing a warning for the ID doesnāt make sense. I looked at the js code and found that they attached the submit() event to the keap-payment-method element. So you can trigger the form submission directly by targeting the tag.
So if you want to make it easier to target the ID attribute youāll get a warningā¦ however, if you donāt pass an ID and they change the custom HTML element tagā¦ youāll have to update your code in more than one placeā¦ :\
So if you pass an ID,
Indeed, I changed it to a class, and then targeted it by the class name everywhere in the code.
Another issue which Iāve missed mentioning is that in their script at:
https://payments.keap.page/lib/payment-method-embed.js
they are setting the iframe width and height attributes like so:
iframe.width = 600;
iframe.height = 420;
which then results in an iframe which is overflowing in the narrow column which I have it embedded in.
And hence, the only solution I have to that, at the moment, is the following:
let keapInterval = setInterval(function(){
if(document.getElementsByClassName('keap-payment-method')[0]){
clearInterval(keapInterval);
document.getElementsByClassName('keap-payment-method')[0].shadowRoot.querySelector('iframe').style.width = '100%';
}
},1000);
Which of course, is less than ideal. At first, I had set the interval to 200ms, but then sometimes the iframe was taking longer to load than that, and the style.width on the ShadowRoot was being applied too early and had no effect.
Hi all,
I am going to share you my experience and thoughts regarding Keap Payment Gateway.
Several years ago I created Order Forms using the standard XML-RPC API endpoints to process the card payments. But due to client requests and European Union regulatory changes, this was no longer possible, and I no longer use Keap API to handle card payments.
Over the years Keap have stopped supporting particular payment gateways, which in turn has caused some of their customers to find alternative gateways if possible. Nexus Merchants was designed to be a bridge between Keap and other payment gateways. Unfortunately, due to particular reasons the company has ceased operations.
In the third quarter of 2019 the European Union wanted Bank and Businesses to start authenticating payments (ie: 3D Secure) at specific intervals. We asked Infusionsoft (was not Keap then) what they were doing to do to support this due to the API having no support for it. Infusionsoft kept very quiet, as the deadline drew nearer and nearer, they still kept quiet. I found out from a Partner they would use a third party service for their online webforms, but still had nothing for their API. I had to alter a particular client Order Form to use Stripe and its Authentication methods. That was not a straight forward process given how the form was originally designed to work with Infusionsoft API. The European Union temporary suspended the deadline given that not all banks and businesses were ready, which was a temporary reprieve. A year or so later the authentication started to become into operation.
Keap are going from bad to worse over the years, and this New Payments API is another fiasco.
- Rushed Decisions were made. Why was a 6 week deadline introduced? Did they think developers would be immediately ready to make the changes?
- Documentation is not good enough. No mentioning of about the payment gateways supported, nor the differences in the form interfaces.
- Keap took the lazy approach with the API as they did not want to disturb things, like adding new functionality to the XML-RPC.
- Requiring that a Session Key is needed against a Contact ID was the wrong approach. When dealing with Payment Gateways you submit the Card details to an URL Endpoint, in which a Token is provided. The Token is passed back to the server to use to charge for the payment.
- The Session Key requirement has caused developers to alter their single page to two page forms, or alternative ways to get around the issue.
- Again, there is no support for Authentication. This questions about Keap and the countries it is targeting for, because it points they want to concentrate on the USA market only.
- Keap changing the attributes and now warning they are deprecated shows they did not properly think about the design. I am sure some of you are not happy have to change the code again.
- No way to apply any styling to the Payment Form. I am sure some of you are not happy that you had to alter the styling to match things.
- You can also see that Keap are no longer interacting with this particular community much. No one officially has responded to this topic Another stupid thing is having a separate community in which staff respond to, but when its integration related they either try to respond or divert it back here.
Going forward, I recommend that in the future you integrate with the payment gateway directly, instead of using Keap API to handle the payments. Some of these payment gateways will have official SDKs making it easy to work with, others may require developing the integration for it. After you get a response back from the payment gateway, all you would need to do with Keap API is to add the Order and Payment against the Contact. If you need to do Subscriptions, then you would either use the payment gateway or build your own solution instead.
2 Likes
Hi All - Sorry if youāve already ran across this, but I didnāt see it in the thread and wanted to post it as a PSA. For those of you that did make the switch to the new payment method. Originally it would return a CreditCardId in the PaymentMethodId field. It now appears that has been updated in the last couple of days to actually return a new PaymentMethodId instead of the CreditCardId - further disrupting the payment workflow.
Again - if you already caught this and were able to pivot awesome! It definitely happened over the past day or so as I can confirm our last successful order through the form was on 4/5.
Just wanted to post this in case you noticed a sudden lull in new orders.
1 Like
I have reported this sudden silent change returning CreditCardId instead of PaymentMethodId to the API support team for clarification, but the ticket was marked as closed without any answer from Keap team.
[case_id=500WQ00000bJY8pYAG]
I would guess that Keap is in the process of no longer retaining CC data on their servers, and fully off loading payment processing to the merchant account. The problem is that theyāre doing it wrong.
The current issue thatās preventing this from working is the false positives being returned. Those false positives are being returned as a result of logic error(s).
While the JS response returns { paymentMethodId: 0, success: true } . The Keap code base receives the following error message from Authroize.net:
Authorize.net: Failed to create token for Authorize.NET: A duplicate record already exists. (E00039).
So because the CIM profile already exists the logic inside of the Keap code base says all is good, and returns a success message with an unusable payment method id.
I deleted my the CIM profiles from my Authroize.net sandbox account, and the JS payment bundle started workingā¦ until it didnāt and I started getting the same issue. Deleting the CIM profiles again allowed the JS payment bundle to resumeā¦ so that bug is still persisting.
Yesterday, I was working on an order form template and I got this error on the Keap hosted order form:
Unable to charge because the payment profile was removed in Authorize.net. This card cannot be charged and should be re-authorized by the cardholder or removed.
The biggest frustration I have, is that in both of these cases, the full CC data has been submitted. From the customers point of view, theyāve done everything they needed to do to complete the purchase.
Iām guessing that the only way to resolve this currently, is to remove all of the credit card profiles from the customers record so they can try again. ā I assume this will work, but Iāve not tested it yet, since every true successful test on the JS payment bundle creates a new CC on the contact.
So having said all of that, Iām under the impression that Keap is moving toward a system similar to how Stripe handles the processā¦ but their logic flow is very flawed, and Iām encountering these issues because Iām a developer.
This has been the biggest pain in the XXX.
I find out today after a few weeks that the response from Keap sends back a different id from paymentMethodId and not the credit card id which it was originally doing and which we built the logic based on. And now they send the creditCardId which obviously makes more sense but wasnāt doing that nor was it documented that way. So we havenāt been having new sign ups card process correctly. So now I need to go through multiple apps updating this when nothing was ever communicated of this change that happened what appears to be Apr 2 or Apr 3.
Super frustrating!!