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