A payment/subscription workflow

Webcraft
, ,
1

Continuing the discussion from August 28, 2019:

Specifically, a way for folks to begin paying me to host their blogs! The details of such an amazing deal with stellar support shall be revealed later, but I can’t publish that unless I’m ready to accept that sweet blogger dough (bloggers refer to money as “sweet dough”, just one indicator I know my target audience).

Use case

After some digital paperwork has been signed, it’s time for my customer to pay me. Not just once, though! No, I would like to rake that sweet dough into my pillowcase (all “blogger” terms) monthly!

One way to describe it is: a web form that accepts information required to process a payment, on a schedule

Stacks (tech and cash?!)

Let’s translate that to a stack of components to piece together:

  • web server to host the form, securely
  • the actual form
  • payment processor
  • integration of form with payment processor
  • scheduled payments (the subscription plan)

Okay, this document is given shape! I already know what I’ve chosen, and the options from which I chose. It will be helpful to tip my ham (blogger speak to spilling a story “early” [bloggers and their meat idioms!]):

I’m using a WordPress (web platform) instance with GravityForms (forms and integration) to start subscriptions at Stripe (payments and subscriptions).

Let’s get started!

2

How often do you fill out forms online? All the time, ne? Each login, anytime someone wants you to pay them, meaning nearly every other website you go to.

Have you ever tried to make a form, to get information from people? It’s tough. I get the unfortunate situation with everyone reaching for Google Forms and embedding it. But Google is :ng:, and actually quite limited in functionality. There are a handful of self-hosted form projects. Just full on: this is web software for building and hosting forms.

I use WordPress, partly because it has it’s own forms as plugins ecosystem, and the rest because WordPress is actually pretty good at this kind of thing. I’d love for another form project to get as easy and ubiquitous to install as WordPress (hello@maiki.xyz if found).

Among the form plugins I’m going with GravityForms. I recommend GF, but not as the sole option. There are some free forms that do most of what GF does, and whereas I have the expensive annual developer license, I believe this workflow I’m building can be had for a lot less, starting from scratch.

But I’ve already got GravityForms, and it is a great product. Among their 30 or so sub-plugins, only about half a dozen are generally useful, including the payment processors (PayPal will be mentioned later, and GF supports that service). The rest are basically integrations to every CRM and email-chain-processing-thing service under the sun.

For my purposes I’ll be using just two sub-plugins:

  • GravityForms - Stripe: payment processing
  • GravityForms - Mailgun: email delivery

Astute readers will notice I failed to mention the email delivery in the outline; I didn’t forget (maybe I did…), I just haven’t determined if I’m using it yet. Of course a self-hosted server should have a way to deal with transactional email (receipts, automated messages, those kinds of things), which includes jumping through more loops than I’m willing to professionally. Hence Mailgun.

Or not. I might have Stripe handle the transactional email in this case. If so, there will be a bonus GravityForms - Webhooks section. :slight_smile:

WordPress is fine for this. I do host these things. Cert from Let’s Encrypt, OS updates, standard WordPress security procedures.

But my formal site has a design element working for it: I don’t want to store any information on the server.

It is useful to think of it as using WordPress to customize the entry point into Stripe’s database of transactions, in order to get the monies delivered. Given my use case, I don’t actually need any other information from a form submitter, aside from their payment credentials, and of course I have absolutely no reason to even store that data.