I had a call yesterday with a friend who was trying to keep the payment dynamics on his site relatively simple. On top of that, his approach to interacting with his clients was novel – and one I appreciated.
So imagine that you're this guy – a designer – and what he does is shows some work on his site. The work he displays is the basic stuff. It could be web site templates, it could be logo templates, it could be movie clips. The medium is unimportant. How he works is what's important. Because what he does is lets a prospect review the “raw materials” and then they collaborate on the product. Only then, after they're both happy, does he send them an invoice to pay.
Now the invoice part of the process was outside the scope of what I was working on, because today there are some cool plugins that do that – like this one by Austin Passy: WordPress Invoice Pro.
He just wants to get paid!
By the time he wants the customer to pay, he already knows a few things:
- He knows the user's email.
- He knows the transaction or order ID that he's assigned to this effort.
So at this point he really needs a simple way to have the customer pay him, without running a full blown e-commerce solution.
So the solution I proposed was a slimline approach using a single form by Gravity Forms. With their fields for pricing, it's pretty simple to pay with Gravity Forms.
So here's how the workflow would go:
- User browses stock imagery and initiates contact.
- The user gives his/her email and the designer captures it, and assigns an orderID.
- They trade emails, iterating over a design.
- When they're done, the designer sends them an email with a URL link to a payment screen.
- The designer also zips up the design file, names it according to the order ID, and places it on the server.
- The payment page holds a Gravity Forms form, pulls some info off of the link, and collects payment.
- The form then sends the user an email link to the file.
- The user clicks on the email link and downloads his file.
Gravity Forms to the Rescue
Once you read the steps, you can see how easy it is for Gravity Forms to do it's thing.
Create the Form
The first thing we'd do is create the form.
You'll notice that on this form there are a couple fields that are super critical – the price field, grand total, and credit card (payment) part. Without those, you can't collect payment. The other thing to note is that this presumes you have an SSL certificate on your site so that you can collect and transmit this data.
Fields that are Hidden
But there are also a couple other fields on here that you'll never see (email, orderID). That's because I've set them to Admin visibility only. The user never sees them on a form. But I do fill them out. I do it by passing info on the URL. It's simple enough in this case and the designer will know it.
A Smarter URL
So instead of https://chrislema.co/pay-me-now-dude/ the url could be https://chrislema.co/pay-me-now-dude/[email protected]&orderID=12345
I find that very few people will try to pay your invoice for you, so you don't have to worry about an email and transaction ID going out on a query string.
The benefit of this approach is that it's incredibly easy to process payment without creating a membership site just to collect the info or direct the user to the right file. But let's be clear, we're using conventions here, not pure code, to solve our problems.
At this point you may be wondering how we got that value on the URL down into our form. The answer is the Advanced Tab. It let's you check a box that says the field will be populated dynamically, which it will, in our case. Then we put the variable name that we'd be passing in the url. Again, that's only emailID and orderID. By keeping them simple, we'll always remember them.
Now the fields are captured and available to us.
The Return Email
You might be asking, why do we care about this info in the first place (emailID & orderID). The reason is because it helps us with our final step – the delivery of our digital file after they've paid. We only want to send them the email after we've processed payment. And we don't want to manually have to do things. So to keep it as automated as possible, we'll use some more conventions.
Our approach suggests:
- The designer deposit the file in a folder that is web accessible.
- The designer names all files the same way (orderID.zip).
- The client's email is a useful way to reach them.
What you see here is the mail merge feature of Gravity Forms – as we use the OrderID in the email subject as well as in the url. By doing this, as long as the designer drops the file into the same place every time, and our emails go out – we'll be sure that the client can get what they paid for. In a simple way.
So that's how you create a simple file drop with an easy to use (and create) Gravity Forms – based payment screen. Could you get more funky? Sure. If you wanted, you could have designers upload the files using Gravity Forms as well, and even integrated it to Drop Box. But that's a post for another day.