slogsdon
commented
7 years ago Hi @colinmollenhour! Thanks for bringing this suggestion.
From a high level, I don't see any issues with this sort of workflow, but we would want to ensure there aren't any problems during checking with the token stored in the checkout session. Also, we would probably want to expose this functionality behind a feature flag to ensure the current checkout experience is the default (at least at first).
I can't think of any great reason why the token shouldn't be saved in the user's checkout session data instead of just on the user's page. Currently if the user goes back to any of the previous checkout steps their payment data is lost and they have to re-enter it again. I propose that the token, CC type, CC expiration, CC last 4 and length of CVV be saved in the checkout session so when the payment step is loaded if a token is already present a new one will not be required. To support this for the iframe method when loading the payment step with session data present rather than try to populate the fields with masked data the form could just be hidden and a link could be displayed that when clicked would display the form and if it is not clicked then the existing token is used.
Edit: For a little bit of extra caution the token could be cleared if the shipping address is updated. This way if the session is hijacked the token cannot be used to place an order to a different address. Also, if the token is in the session just expose a flag like "session_has_token" to the UI rather then rendering the token into a hidden field.