CORS Support for Direct Post

[dmdaniel]

Currently it is not possible to implement a checkout experience with Direct Post that keeps the customer on the checkout page without redirection. We would to avoid redirection to improve the checkout experience.

This redirection-less checkout is possible with the Payment Pages 2.0, using the javascript callback, however we are finding that conversion rates are not great with the current checkout design and we would like to improve the experience by adding more real time feedback as well as better validation for direct debit customers - which are not possible with the iframe.    

Our ideal design is one where the form is posted directly to zuora via ajax.  However we are finding that this is not possible as the /apps/PublicHostedPageLite.do page does not support the CORS header "Access-Control-Allow-Origin" and hence cannot be called directly form the customers browser (although this is exactly what happens with the iframe).  This leaves us with two choices (neither of which are ideal):-

1) Rely on redirect, which limits the design of the checkout.

2) Implement the ajax call through our server, and pass that on to Zuora.  However, this adds an additional touch point for the card details.

It would help with the checkout experience if the  PublicHostedPageLite page supported the CORS header to make this possible.

[keenan]

Creating a credit card payment method using CORS header is currently supported in our REST API. This would give you the control over the checkout design similar to direct post.

https://knowledgecenter.zuora.com/DC_Developers/REST_API/A_REST_basics/G_CORS_REST

We're are planning to expand the supported payment methods in REST beyond credit cards in the coming months.

Keenan

[dmdaniel]

Hi Keenan

 
Thanks for the feedback, in our case (and i think this is pretty common) we do not have the account set up at the time we are doing the order.  Hence the Direct Post solution is ideal as this allows a 'annonomus' capture of a payment method that is later linked to the account when it is created. 

With the CORS version of the payment capture (https://knowledgecenter.zuora.com/DC_Developers/REST_API/B_REST_API_reference/Payment_methods/1_Crea...) we would need to know the accountId at order time - which does not fit with the natural order flow process.  

The other advantage of the Direct Post is that it supports signing of the response from Zuora, if we do not want to trust the broswer we can verify the advanced Zuora signature server side to ensure that nobody has tampered with the paymentmethod id. (Incidenlty signatureType: advanced does not seem to work with submitEnabled: true, meaning the paymentmethodId can be tampered with on the browser when using the javascript methods).  This isn't currently possible with the REST call you mention.  

daniel

[Togg12345]

Hi Keenan,

I would like to upvote the feature request for ACH support under CORS via the REST API. While I understand this doesn't solve the root issue in this ticket, it is desirable for our workflow. We want to abandon hosted page integration for some of the same reasons suggested here (validation, styling, UX orchestration) but cannot support ACH any other way. Direct Post, of course, doesn't work because we rely on Hosted Page for PCI compliance. CORS REST solves both problems.

Thanks for your consideration.

-Todd

[Togg12345]

Hi Keenan,

Have there been any updates on the prioritization of ACH CORS support?

thank you,

Todd

[Erinne]

Hi Keenan,

Any updates on the above?

Many thanks!

Erinne

[Togg12345]

Hi there,

Just checking on this! Wondering if there have been any updates?

thanks,

Todd

[megamind]

I too need this! Please update!

[megamind]

I too need this! Please update!

[paulkaiser]

We would like to see this implemented, also.