What I found confusing was how customers were emailed about needing to make this update without confirming any apps that have made this update. It is good they get notice to make sure they’re prepared, partners were also emailed on this.
But for a customer using an integration like ClickFunnels that needs this update made, is it really the customers responsibility to make sure CF updates their code here?
How do partners and other users know once an integration have successfully updated their code with this update? Without a list of providers shared, Keap’s messaging is alarming that a customer’s ability to collect payments is going to stop on March 20.
It’s also concerning if Dustin and everyone here, except @Marion_Dorsett2(?), has not been able to complete this update successfully so far
Heya, Jeremy here (FuseDesk, FeedBolt, etc) with our two cents. First, to @Andrew_Pfund 's question, where needed, we are implementing this change in our products so it’ll be a seamless change to our customers.
The thrown together JS integration provided is still full of debug code and looks like a first draft at best. The documentation is poor, and the error reporting vague. We’ve been able to successfully get our session key, validate it’s good, embed the widget, submit the form, and listen for the event, but the errors that come back from Keap don’t give any details as to why the updates fail. Even worse, the error message from Keap is simply Operation currently not supported which is understandably concerning…
We’ve reached out to Keap PMs and dev support about this and haven’t heard back as of yet.
It is our expectation that this library will change/improve in the future, and given the spate of breaking/urgent Keap developer changes that have been rolled out in the past 12 months, we expect there to be limited time to implement said changes.
It is our hope that improvements will remain backwards compatible - or at the very least versioned so existing code works while improved libraries are implemented. It is also our hope that Keap supports the integration community in getting these required changes implemented before breaking deadlines hit.
Just heard back from Keap Developer support. So not all merchant accounts are supported.
If your default merchant account in Keap isn’t supported by their new billing widget… the billing widget won’t work at this time.
I’ve asked why that matters and how we can specify which merchant account to use for a session key or for the billing widget form and will update here as I learn more.
Hi All - First time poster, but have found all of your responses VERY helpful (THANK YOU ALL). This might be “old news” but figured I would post this here in case someone else runs into the same issue.
As some have already stated, the error coverage is almost non-existent and there is a chance you can run into a false positive. E.g. success = true and paymentMethodId = 0.
Thankfully up until today, the form was “working” for us until I finally ran into the false positive. After much digging and testing (and an attempt with support which didn’t go anywhere unfortunately), I found that there’s a limit on the number of profiles with Authorize.net (10). I figured that deleting the cards in Keap would address the issue, but unfortunately that didn’t seem to help matters. Someone else might know, maybe they don’t delete the authorize.net profiles immediately? But, because of testing, I had hit the limit on a test account.
Once I swapped to using another test account / contact, the happy path worked fine again and the paymentMethodId was returned like normal.
Either way, not GREAT news, but at least wanted to provide this additional false-positive in case anyone else’s all of a sudden “quits” working.
I ditto what @Pav said above - we are also extremely concerned that we have to convert all of our order forms which are Single Step process into a Two Step order form process. We have hundreds of checkout pages, our entire business relies on them, and to have them all converted within a few weeks is unreasonable to say the least.
And then, like @Dustin_Lunt said - the inability to change the design of the credit card inputs will inevitably affect our conversion rates, because the iframe they are providing us with doesn’t match the existing design of our contact information, address, billing, and shipping fields. I contacted their support to ask about this, to which they replied: Thank you for reaching out to us regarding the ability to edit the CSS of the credit card form. At the moment, this feature is not available. However, we have submitted your feedback to our team on your behalf.
And to top it all off, the credit card fields validation is poor to say the least. For example, a credit card Expiration of 01/12 passes the validation.
The fact that Keap is populating the CIM in Authroize.net is wrong. It’s not necessary to add the card to the Keap contact record. The card can be validate against the appropriate algorithm(s) and once the card is charged and authorized, the payment confirmation will determine if the card is actually valid.
The whole false positive for this use case goes away if they simply stop adding customers to the CIM… but Keap support refused to debate this issue and decided to move on since I was able to get the payment id back.
Marion, Now I’m getting the paymentMethodId = 0 after I’ve successfully tested it several times. Is it just a security thing that causes a contact record to only allow so many cards to be added on a contact record before it starts returning 0? Was the only way to get it resolved to open a ticket for it so that they remove the block of something?
The initial issue I had was that because the customer existed in the Authorize.net CIM, the response Authorize.net API was returning a duplicate record. Once the Keap devs resolved that issue I have honestly not had any more issues.
I’ve been testing with a Sandbox account, but my client and I were able to successfully merge the code into their production environment. We’re still tweaking, but so far we’ve not hit any significant issues.
I’m at a loss for any reason why Infusion is doing anything w/ the CIM - especially - since it’s optional, and it appears to be the cause of some of these issues…
I took the time and I setup a very basic working setup that you can download here:
I did NOT setup the process-order.php script to actually process an order. I set it up to show the POST data sent back once the full form has been submitted w/ the contact id and payment method Id.
The step 1 part of the form will work, after you’ve configured it to work w/ your implementation of the iSDK.
Regarding the embeded iframe, is anyone else seeing a large amount of white space below the form?
Also if the user does not fill out the form, but still clicks submit, it seems that we do not get any event back from Keap. We would prefer to be able to throw an error popup when this happens.
The red is the space taken by the iframe. The spacing between the input fields is consistent, and the same padding is applied to the postal code field, combined w/ the padding of the iframe, Making it appear as if there is more white space at the bottom of the iframe.
Our iframe appears like this on both Linux and Windows machines, on both Firefox and Chrome.
There are extremely minor differences for the CVC default text font and size, and the text clipping seen in the above screenshot (taken in Linux Firefox) only appears in that OS/Browser combo. That’s all we noticed, though.
Because Keap populates the CIM in Authorize.net, which requires the name, it now makes sense why they’re asking for the name, and depending on the AVS setting it also explains country and postal code.
