Allow user-specified values for interval, frequency and trial-period in custom-amount Subscriptions

[nikolowry]

Description

Requesting the ability to allow user-specified values for interval, frequency and trial-period in custom-amount Subscriptions.

I'm currently porting an old Craft v2 site to v3, in which they are currently using the Charge Plugin to handle single and recurring payments for donations. They currently accept recurring payments with monthly/quartely/yearly frequencies and with durations lasting 1-5 years.

It would be a breeze to implement with Enupal Stripe if it was something that could be set during runtime in the form's POST data, but it seems that those values are explicitly driven by each payment form: https://github.com/enupal/stripe/blob/6a32cbad77ff8a082e67c14d494a74debe5217fc/src/services/Checkout.php#L141-L150

I'm trying to decide now whether I should:

• Create 15 payment forms with the only difference being interval/frequency (a clone form button would be awesome)
• Use the "customer chooses plan" option and then create a Module to act as a "middleware" that would create the custom plan/subscription, sync and add back to the payment form, and then finally process it with Enupal Stripe's Checkout service. I don't think this will be viable though because they have 1000s of unique products/pricing plans in their Stripe dashboard.
• Patch Checkout.php to use post data when creating the custom plan and use metadata to record the "real interval/frequency"

Any advice would be appreciated

Additional info

• Craft version: 3.3.19
• PHP version: 7.2
• Database driver & version: MariaDB stable
• Plugin version: 2.2.0

[andrelopez]

Hi @nikolowry I see your point. We could add support to pass the interval/frequency via options for custom amount subscriptions when you display the payment form, e.g:

{% set options = {interval: 3, frequency: "month"} %}

{{ craft.enupalstripe.paymentForm('handle', options) }}

Any thoughts?

[nikolowry]

@andrelopez thanks for the quick response! The snippet you provided seems like it would suffice. I'm assuming a similar option could be added to specify trial period days?

I was wrong about assuming I'd currently need to create 15 forms -- it would only be 3 (30 days, 3 months, and 1 year), plus some JS to update input[name="enupalStripe[formId]"] and a few other inputs when my custom select's emit changes.

Would you happen to know if the customer.subscription.created webhook is the best way to implement a Subscription Schedule?

Would that same webhook, customer.subscription.created, currently be the best for adding a custom trial_period_days -- I believe there's about an hour to update subscriptions prior to Stripe processing the payment?

Appreciate any insights you can provide!

[nikolowry]

Updates

• Went ahead with 3 unique forms, figured it be easy to delete 2 then to revert any custom patches when this feature makes it in.
• I'm using Stripe Elements, so in the original post I should have linked to these LOC in the Orders.php service: https://github.com/enupal/stripe/blob/aef71f577eae5bc35b2055679fc497b1b9fc1c4c/src/services/Orders.php#L1173-L1182
• customer.subscription.created was the Webhook I needed to add a Subscription Schedule

---

While I was able to get around most of my blockers, I discovered an oversight with the current free trial period implementation.

The site I'm porting had been using trial_period_days to allow users to specify when their first donation was paid. I was trying to avoid patching Orders.php by adding a 1 day free trial period to each single payment custom amount form. Figured I could immediately update the trial amount using a webhook and some values in Stripe's metadata.

The custom plans created all showed the right amount of free trial days, but every invoice kept getting finalized and charged immediately. The trial_from_plan parameter was missing from the create subscription request.

I ended up creating the following patch to get around it at the moment (and to be able to set it from the POST data):

diff -rupN a/src/services/Orders.php b/src/services/Orders.php
--- a/src/services/Orders.php   2020-03-10 23:03:53.226114397 -0400
+++ b/src/services/Orders.php   2020-03-10 22:41:16.366571316 -0400
@@ -1170,15 +1170,18 @@ class Orders extends Component
             "currency" => $paymentForm->currency
         ]);

-        if ($paymentForm->singlePlanTrialPeriod){
-            $customPlan->trialPeriodDays = $paymentForm->singlePlanTrialPeriod;
+        if (isset($data['trialPeriodDays']) || $paymentForm->singlePlanTrialPeriod){
+            $customPlan->trialPeriodDays = isset($data['trialPeriodDays'])
+                ? $data['trialPeriodDays']
+                : $paymentForm->singlePlanTrialPeriod;
         }

         $plan = StripePlugin::$app->plans->createCustomPlan($customPlan);

         // Add the plan to the customer
         $subscriptionSettings = [
-            "plan" => $plan['id']
+            "plan" => $plan['id'],
+            "trial_from_plan" => true
         ];

         // Add tax

Should I open a new issue/PR for this? Or does reporting it here do?

[andrelopez]

Hi @nikolowry I can continue from here. I'll let you know if I have any questions. Thank you for following up

[andrelopez]

Hi @nikolowry We just added support for custom plan options on Stripe Payments v2.4.0 more info here

Thank you for your feedback

[nikolowry]

Appreciate it @andrelopez!

[andrelopez]

@nikolowry I forgot to mention that if you're using template overrides you need to add lines https://github.com/enupal/stripe/blob/cbab3e576567b62dcdd13ffe31d89732ebca424c/src/templates/_frontend/paymentForm.twig#L26 26 to 34