New Payments API Integration Configuration - Rushed Decisions and Timeline

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

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

  1. First, this billing widget will ONLY work with your ā€œdefaultā€ merchant account and not any others you have configured.
  2. 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.
  3. 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.
  4. 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.