Okay, a state machine sounds a little fancy, but the idea is to map out all the states needed to be able to support payment in a single form.
The form would contain the auto-generated CC fields, and the personal details (name, address etc.). LOTS of things need to happen in the right order for this to work.
The CC form can only be displayed with a brand new session key.
If a new session key is generated then the CC form needs to be redisplayed.
If the session key or card identifier expire, then the CC form needs to be redisplayed.
Either may expire by time (so with no real warning) or if they have been submitted with invalid data too many times, e.g. invalid postcode format.
The whole form will not submit unless the CC data correctly tokenises.
If the address fields fail local validation, then the form needs to be represented for correction, but there is no need to reshow the CC fields again (the card identifier can be put into a hidden field).
The same applies for remote validation errors, to a point.
The card identifier may be found to have expired on the final transaction request, in which case the form needs to be shown again so that CC fields can re-entered for tokenisation. However, we want to keep the personal details fields that the user may have edited to get this far past the validation.
In short, one simple success path through, but MANY things that can expire or be found to be invalid at various stages, with jumps back to earlier stages in the path needed to pick up on those exceptions.
We also need to think hard about how JS validation of personal details would work, since it needs to work alongside the CC details validation. Perhaps the way to handle that would be a callback on successful tokenisation of the card to physically remove the CC form fields immediately so it won't be accidentally tokenised twice (the second time of which would fail).
Also note that the AJAX tokenisation may also discover the session key is expired or overused, and so need to fetch a new from the server to retry tokenisation.
It might make more sense as a spreadsheet. It's had me stumped for a long time. My solution at the moment is to have two separate forms on two pages - the first to collect the CC details and tokenise them (AJAX) and the second to submit the personal details. Once the user is past the first form, they can submit the second form as many times as needed to get through local validation, before eventually sending the payment request. It's not as smooth a UX as it should be as a consequence.
Okay, a state machine sounds a little fancy, but the idea is to map out all the states needed to be able to support payment in a single form.
The form would contain the auto-generated CC fields, and the personal details (name, address etc.). LOTS of things need to happen in the right order for this to work.
In short, one simple success path through, but MANY things that can expire or be found to be invalid at various stages, with jumps back to earlier stages in the path needed to pick up on those exceptions.
We also need to think hard about how JS validation of personal details would work, since it needs to work alongside the CC details validation. Perhaps the way to handle that would be a callback on successful tokenisation of the card to physically remove the CC form fields immediately so it won't be accidentally tokenised twice (the second time of which would fail).
Also note that the AJAX tokenisation may also discover the session key is expired or overused, and so need to fetch a new from the server to retry tokenisation.
It might make more sense as a spreadsheet. It's had me stumped for a long time. My solution at the moment is to have two separate forms on two pages - the first to collect the CC details and tokenise them (AJAX) and the second to submit the personal details. Once the user is past the first form, they can submit the second form as many times as needed to get through local validation, before eventually sending the payment request. It's not as smooth a UX as it should be as a consequence.