My usage of Ghost principally revolves around publishing a print edition of our online magazine, using the existing infrastructure for paid subscriptions. That means we need to be able to collect shipping addresses for paid members of the site.
Luckily, Stripe makes this easy by allowing you to add shipping address collection to the Stripe Checkout payment form with a single API parameter. The member’s shipping address would then live entirely within Stripe, not in Ghost, and likewise the member could access a Stripe customer portal to update that shipping address.
Unfortunately, Ghost simply does not present a configuration setting to enable shipping address collection in Stripe sessions. (I presume this would be passed in here.) That means, as a Ghost(Pro) customer, I only have the following options for collecting this information:
-
Redirect members to Stripe’s customer portal URL to update shipping address info, which requires multiple steps to get to, including an email login and confirmation, for something that is rather difficult to explain to a user. (“Yes you just subscribed and paid on Stripe, but now click through several other dialogs, including an email link, to go back to Stripe to add in shipping info.”)
-
Integrate some kind of user shipping address collection form totally separate from Ghost or Stripe, using Google Forms or some paid alternative like Typeform, which is triggered on new subscriptions (possibly requiring a paid plan for Zapier?). Then perhaps manually entering that info into Stripe for the customer.
Option #1 is nice because it comes with Stripe’s address validation. Option #2 is prone to typos and other ill-formed addresses, not to mention possibly costing money for third party applications.
So all in all, this might make the difference between Ghost(Pro) and Ghost on a third party hosting site. But why not just add a setting to enable shipping address collection in Stripe sessions? Is it just a matter of someone – like me? – sending the PR on the Ghost Github project? Or is there a more fundamental reason why this should not be supported?