Stripe best practices

[rlicopoli]

The transactions work. two items:

1) Can you add "transaction description" to the form? its not listed and is important inside stripe.

2) The form address isn't transfere to the stripe checkout module, meaning address information has to be entered twice.

3) transactions are successful however I am getting the following error after checkout. I am sure it's my fault as i suck ad user id and id stuff:

ERROR
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 3 SQL=SELECT `id`, `title` FROM `#__usergroups` WHERE `id` =


Great job so far. A few more tweaks and we should be good to go live.

 

[cheesegrits]

1) Can you add "transaction description" to the form? its not listed and is important inside stripe.

By "transaction description" do you mean the "item" text, which is then attached to the Stripe transaction as the "description", and shows up on your Stripe dashboard payments as "Description"?

And by "add to the form", do you mean display it, if you aren't using a form element for that purpose?

I'm playing around here with the best approach for that, about to commit something that lets you specify some text to put at the botto of the form, which can use placeholders {stripe_item}, {stripe_amount} and {stripe_last4} (for existing customers).

2) The form address isn't transfere to the stripe checkout module, meaning address information has to be entered twice.

Can you describe your setup / workflow?

The way it works at the moment (simply because this was the first use case I needed) was that you can have the Stripe dialog capture billing and / or shipping address, and this plugin can then enter that information into your "customer" list (a separate list from the order form), optionally creating a new row in that list if there isn't one for the logged on user, along with their newly created Stripe customer ID.

I presume in your case, you are capturing their address elsewhere - either on the order form, or in a separate customer table - and want to add that to the Stripe capture dialog? Which I don't think can be done. Only the email can be preset.

3) transactions are successful however I am getting the following error after checkout. I am sure it's my fault as i suck ad user id and id stuff:

That's not coming from the Stripe plugin. And there's nowhere in our code we run a query that looks exactly like that. The closest is in the 'usergroup' element plugin, but we don't `quote` the id and title in that one.

-- hugh

 

[cheesegrits]

So. Part of what I'm trying to work out atm is how to make this plugin useful in two different scenarios:

1) A "static" order form. That's pretty much what we have right now, where you figure out the amount and the description in the eval'ed code. The usage case I'm building atm is a membership dues form. So we figure out the amount and description from the logged on user ID, looking up their membership type / cost in a table. That information is not held in any elements on the payment form. Although I am about to add a way to specify that the values you eval then get stored in elements on the form.

1) A "dynamic" order form. Let's say you sell pies - which happens to be my standard test setup for the PayPal plugin, mostly because I was building a demo where you could then chart your sales, and I wanted to have a Pie Chart. Anyway ... so you would have an order form with:

Which Pie: <database join element to 'pies' table ... apple, pecan, cherry, etc>
Quantity: <field for number of pies>
Cost: <read only, probably a calc using AJAX, which figures the cost from type and qty of pie>

And that data would have to be collected within the Javascript that opens the Stripe collection form. Which is slightly problematic, because if the "Which Pie" is a join element, the "value" isn't going to be a descriptive string, it's going to be a numeric key. So we'd have to know whether we want the "value" or the "label" of that selection.

It's usage 2) I'm still trying to figure out how to do. This isn't something we had to solve in the PayPal plugin, because there's no client side processing. PayPal all happens on the server side, during form submission, where we can eval the user's selections (qty * cost). We don't have to figure it out on the form in JS, which we do for Stripe.

-- hugh

 

[rlicopoli]

good stuff. I fixed the sql error above. thanks for addressing

By "transaction description" do you mean the "item" text, which is then attached to the Stripe transaction as the "description", and shows up on your Stripe dashboard payments as "Description"?

And by "add to the form", do you mean display it, if you aren't using a form element for that purpose?

I'm playing around here with the best approach for that, about to commit something that lets you specify some text to put at the botto of the form, which can use placeholders {stripe_item}, {stripe_amount} and {stripe_last4} (for existing customers).



Can you describe your setup / workflow?

The way it works at the moment (simply because this was the first use case I needed) was that you can have the Stripe dialog capture billing and / or shipping address, and this plugin can then enter that information into your "customer" list (a separate list from the order form), optionally creating a new row in that list if there isn't one for the logged on user, along with their newly created Stripe customer ID.

I presume in your case, you are capturing their address elsewhere - either on the order form, or in a separate customer table - and want to add that to the Stripe capture dialog? Which I don't think can be done. Only the email can be preset.



That's not coming from the Stripe plugin. And there's nowhere in our code we run a query that looks exactly like that. The closest is in the 'usergroup' element plugin, but we don't `quote` the id and title in that one.

-- hugh

I fixed the sql error. my fault as expected. I will play around with item 1 and 2 above. i believe i have solutions. i will be back on later tonight.

 

[cheesegrits]

OK, I committed some changes ...

https://github.com/Fabrik/fabrik/commit/656d2c6fb45116f71f0b22101cbb0f0efa58bcda

Adds a few new things.

You can specify the text to put at the bottom of the form, with some special placeholders. Although I probably need to add an option to not output anything.

You can "Eval to Element" for Cost and Item. That is, you can select a cost and/or item (description) element, and optionally set them to the values you eval. useful for a read-only element to display the cost / description your eval code comes up with.

-- hugh

 

[uktran]

Hi, is it possilbe to test this plugin by just installing the latest 3.5.2 package via installer, or is a full github update required? I've installed the latest version and clicked discover but searching for stripe plugin reveals nothing.
Thanks

 

[cheesegrits]

You'll need to do a full github update, as it uses some Composer library files which don't get installed with the normal J! package install. I'm working on creating a separate installer for our 3rd party Composer libraries. That folder is just too big to include in the core installer, it's about 10mb. And even though things like the Stripe plugin are available as separate plugin downloads, anything which relies on Composer installed libs need that full ./libraries/fabrik/composer older installed.

Also, the Stripe plugin isn't part of the main package, it's a separate download. We only include about 1/3rd of our plugins in the core package, the "core" ones, again due to package file constraints. We're already knocking up against the 8mb hard limit on JED packages.

So do a full github update, then "Discover" in J!'s extension manager, install and enable the "Fabrik Form - Stripe" plugin.

Just FYI, we're about to go live with our first deployment of it for a client. So I've been working pretty hard on it, and will be pushing some more fixes and enhancements to github soon.

-- hugh

 

[cheesegrits]

OK, I just pushed a fairly important fix:

https://github.com/Fabrik/fabrik/commit/2f021ed234d5aee6b9c3967e1016c3d2c3bb7f3f

... which fixes an issue where the rowid wasn't being included in the Fabrik log event for a successful charge. The plugin logs to our #_fabrik_log table, and the fabrik.stripe.charge.success.stored event is the one you would be useful in any kind of forensic tracking of when / how a specific charge was made - stores formid, rowid, stripe transaction id, user id, date, etc. This is in addition to storing the transaction id in the payment form itself.

-- hugh

 

[uktran]

Before I get too deep into this, can I just check something. It looks from the screenshot, the price has to be fixed in the plugin admin.

Can I just check that if it is possible to use a dynamic net total in a (ideally read only) form field? , from any of these sources?

1/ passed via a url variable into the form view eg

&table___net=123.22

2/ Or using a calc element to pull in a value using a sql query?

3/ simply a advance-edited field in the row?

 

[cheesegrits]

Short answer - yes to all three, when I get a couple of things working and tested, which should be today.

Not so hosrt answer ...

The price can be eval'ed, so you can put any code in there you want.

I would suggest not passing in a value with a query string, or using an actual usable form input. Instead, pass an id to a product table, and look up the price and description from that. Passing an amount directly or taking a value from a usable element on the form is obviously open to abuse. Unless of course your form is designed to let people pay an arbitrary amount that they decide, like a donation.

However ... I'm still kind of working on this aspect of the code. It's working for my usage in our first deployment, where we are calculating a membership fee, based on the logged on userid, looking that up in various tables.

The problem is that the nature of Stripe is that we have to calculate the cost both when loading the form, and when submitting it, because we have to know the cost to pass to the Stripe collection dialog code on the form through JavaScript, as well as to the actual charge API on the server side when submitted. This makes it somewhat more problematic than the PayPal plugin, where we don't give a hoot what the cost is during form rendering, only after the form is submitted.

And of course this makes it difficult if you want to use query strings on the form load, as they won't exist when the form is then submitted. Although you can always just set a form element to a value (&mytable___myelement=100) directly, or use an eva'ed default on an element to pic up a query string value.

For my initial usage, deriving fees from looking up the user ID in tables, it's going to be the same on load and submit, and we can safely do that calculation on both, and it's actually safer to do so as it reduces the likelihood of someone managing to spoof the inputs on the form to charge a lesser amount. So this isn't an issue on my current test case.

What I'm working on is a way of using an element to store the cost calculated on load, then using that element as the amount to charge on submit, rather than re-calculating the cost on submit. Should have that done soon, just got it working, need to do some testing, I'll probably commit those changes within the hour.

-- hugh

 

[cheesegrits]

Oh, thinking about it, doing 3 currently won't work. The design right now assumes that the price is fixed on the server side when the form loads, and can't be changed on the page. Again, this is because that's what my two initial test cases need. So the plugin is currently designed around the concept of "fixed" costs, which are calculated on the server side, rather than variable costs that can be changed on the form.

However, I'm totally up for making that an option, so our code reads the value of a specific element to grab the cost for the Stripe popup when the button is pressed, rather than having that only use the cost that was calculated on the server side during page load.

I just need to understand different use cases, and find ways of allowing them, without compromising other usages.

-- hugh

 

[confis]

I managed to update from github and i can see it now
i try to configure, it but got so issue
find attached configuration images

this is the form before enable the stripe plugin



this is after enable the stripe plugin












any idea ?

 

[cheesegrits]

Ah, I forgot to commit this one:

https://github.com/Fabrik/fabrik/commit/42319c67b56446e75c7dfbbb7367985688bd9101

... which adds a test to make sure you have elected to use a "Customer Table" (for storing the Stripe customer ID in when they make a purchase) before trying to get the customer ID.

Also, I notice that in your "Charge Data" you have selected 'id' as the "Charge ID", which isn't correct. That 'id' is the primary key of your form. What you need to provide there is another element, probably a hidden field, called something like stripe_id, which will store the unique ID Stripe generate for the payment transaction (a string like ch_19eFlMIq6ghgi9dSeZ0Ong0L). When you submit the form, and the plugin processes the transaction through Stripe, we write the Stripe charge ID to that field in the form and save it. Same way you have provided an 'email' element, which we will fill in with the email they specify in the Stripe dialog.

Also ... where are the values in your cost and item element coming from? Are you setting them in an element default?

Remember at the moment, those values have to be pre-set when building the form. They can't be filled in on the form in the browser (yet).

If you explain what you usage is, and what you need the work flow to be, I'll come up with a way for you to do it.

-- hugh

 

[uktran]

Just wondering how the stripe plug in is coming along? Is there a timeline for full release? Will defining net price via a url variable be supported?

Thanks in advance

 

[cheesegrits]

Just wondering how the stripe plug in is coming along? Is there a timeline for full release? Will defining net price via a url variable be supported?

It's ready for prime time now, we are using it on one of our client sites for membership fees. And I demonstrated setting up a Stripe payment in a live demo at Houston JDay last weekend.

Yes, you can use a URL variable, in one of two ways. Assuming your URL has &your_query_string_arg=99.99 ...

1) Use an evaled default on a simple field element, like ...

return JFactory::getApplication()->input->get('your_query_string_arg', '0');

... then selecting that element as the field to use in the Stripe plugin settings for Price. Obviously you can use whatever you like as the query string arg name.

2) What I do is set my element to read only (by setting the new and edit ACL to "nobody" or "Super Admins") with no default value, put the above code in the Stripe plugin Price settings, and select "Eval to element" and the price field as the element to use. Achieves the same effect, but collects all of your Stripe related settings in one place. What happens is that code gets run by the Stripe plugin when the form is loaded, and the result assigned to your price element, which is displayed as read only on the form, and the actual value set as a hidden, encrypted form input.

You might want to add some error handling to that code, to make sure the supplied value is a number, and whatever other checks you want to put on it (like, say min and max valued) ...

$myPrice = JFactory::getApplication()->input->get('your_query_string_arg', '0');
if (!is_numeric($myPrice) || ((float)$myPrice < 10 || (float)$myPrice > 100)) {
   return false;
}
return $myPrice;

... would barf if the value wasn't between 10 and a 100, or wasn't a number.

Note that at the moment, if you return false, the plugin throws an exception, so the form wouldn't render, you'd just get a "runtime exception" error about an error in calculating the cost. I'll probably add some way of providing more user friendly feedback.

To use the plugin, do a full github update, and discover & enable it in J!'s extension manager. You have to do a complete github update, not just grab that plugin folder, as it relies on some Composer installed libraries in the main Fabrik library folder.

-- hugh

 

[ontarget]

Hi,
I am re-opening this thread with regards to the new Secure Customer Authentication (SCA) required by stripe.
Does the current stripe fabrik plugin support the new Stripe Checkout?
My current checkout via the fabrik form seems to be still using the old version of stripe checkout (see image).
Here is a link to the stripe checkout migration / upgrade
https://stripe.com/docs/payments/checkout/migration
Thanks for any info.

 

[cheesegrits]

Nope, I wasn't even aware of that, as the subject hasn't come up with any of my clients that use Stripe.

As soon as I get half a day free, I'll update our plugin.

-- hugh

 

[cheesegrits]

Hmmm. Just read the docs. This is going to require a complete rebuild of the plugin, so don't expect it any time soon. It basically reverses the payment process flow, so instead of generating a token in their JS and then processing that on the server after form submit, the token is generated on the server first, then the JS redirects the user to a Stripe payment page, which then takes them to a "success URL" (or fail URL) on the server.

-- hugh

 

[ontarget]

Hmmm. Just read the docs. This is going to require a complete rebuild of the plugin, so don't expect it any time soon. It basically reverses the payment process flow, so instead of generating a token in their JS and then processing that on the server after form submit, the token is generated on the server first, then the JS redirects the user to a Stripe payment page, which then takes them to a "success URL" (or fail URL) on the server.

-- hugh

Hi Hugh if it helps I can send you a custom php stripe payment web app which I just upgraded to use the new checkout. According to stripe there will be failed payments using the old checkout as of September 14 2019

 

[cheesegrits]

Crap.

I don't think an example would help. I understand the new process and what needs to be done. It's just tough doing changes like that in Fabrik, as we're building everything from first principles on every page load. We're not a "payment web app", we're an app that builds apps from metadata, which adds a whole layer of complication.

I'll block out some time next week to update it.

-- hugh