judgej
commented
7 years ago A little think about how this is going to work.
At the moment, the purchase method initialises the data storage using minimal details, then [will] returns an object used to generate the front end form. However, the front end form then only returns a success/fail status, indicating whether the CC was successfully tokenised or not.
It is then necessary to do the full purchase send at the back end will the full details (names, addresses, basket, CC token etc). So how to organise that?
It seems like we need two purchase methods. Only the backend purchase actually initiates the transaction, so that is the one that should stay. The initialisation for the front end perhaps needs to be a separate method - init maybe?
Should check out how other gateways handle this.
It should be noted that the Checkout Page and Checkout Seamless parameters are constructed in an identical way, with a handful of parameters that are relevant to just one or the other. So there is significant code reuse there.
Unlike Stripe, this gateway does not write its result to the front-end form for posting back to the merchant site. Instead, it writes the CC details direct to the remote gateway through AJAX, using the data storage ID as part of a two-part key.
This uses the approach made popular by Stripe.
For certain payment methods, first a token is created on the gateway directly server-to-server. The gateway also returns the URL to the JavaScript to use. This token is used on the front-end to securely store the CC or other details on the gateway using AJAX.
The token is then used in place of a credit card detail at the back end to submit the transaction creation request.
I'm not sure whether the front end form MUST be generated by the merchant site, or whether it CAN be automatically generated by the gateway JavaScript, so there could be some additional helper functions needed there to at least list the required form fields for each payment type.