Adam-exception

[oak ocean]

The problem is that $paymentMethod is null/empty

[rugged adder]

Right, that what I figured as well, I've var_dump() it and confirm it's null. Is this something on the Form/ JS side that could be causing it?

[oak ocean]

Possibly, it really depends where that variable is coming from and what you're expecting yes. You need to find where you initialize this in your code first and see why it's null and walk back from there

[rugged adder]

I have the following function that is hit once the form is submitted. I've opened up the Developer Console and confirmed that payment_method doesn't exist in the request at all.

function paymentMethodHandler(payment_method) {
    var form = document.getElementById('subscribe-form');
    var hiddenInput = document.createElement('input');
    hiddenInput.setAttribute('type', 'hidden');
    hiddenInput.setAttribute('name', 'payment_method');
    hiddenInput.setAttribute('value', payment_method);
    form.appendChild(hiddenInput);
    form.submit();
}

This is where the above is occuring

[oak ocean]

yep so you need to debug that JS code. Add logs each step to figure out where you are losing the PaymentMethod id

it's all in your code right now at least and with logs you can find the bad line of code

[oak ocean]

@upbeat umbra any luck?

[rugged adder]

I actually went back to the drawing board and completely started over using the exact example form Stripe's documents. So I'm now able to get a charge and customer created, but am searching for how to properly set their default payment method to ensure I can subscribe them after a successful payment.

[oak ocean]

in theory you shouldn't subscribe them after

You should be creating the subscription as part of taking their first payment, is there a reason you're not doing that?

[rugged adder]

Nope, and ideally I would do it just like you said. I've read through https://stripe.com/docs/payments/integration-builder but as part of one of the steps it says I can save their payment info (confirmed that's working), and charge them later

For the payment intent, and creating the customer, this is my approach that seems to work (minus subscribing the customer)

public function paymentIntent ()
    {
        Stripe::setApiKey(env('STRIPE_SECRET'));

        // Create our Stripe Customer if needed
        $this->createStripeCustomer();

        $paymentIntent = PaymentIntent::create([
            'amount'                => 400,
            'currency'              => 'usd',
            'customer'              => Auth::user()->stripe_id,
            'setup_future_usage'    => 'off_session',
        ]);

        return response()->json([
            'clientSecret' => $paymentIntent->client_secret
        ], 200);
    }

    private function createStripeCustomer()
    {
        $user = Auth::user();
        $user->createOrGetStripeCustomer();
    }

[trail crypt]

Hello! Taking over for @oak ocean, after the Payment Intent is successfully confirmed it will attach the Payment Method to the Customer. You can then specify it as their invoice_settings.default_payment_method in an update call to the Customer: https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method

However, if that initial payment is for a subscription, you should be creating a Subscription initially instead, not a Payment Intent directly.

We have a guide for building Subscriptions with Elements here: https://stripe.com/docs/billing/subscriptions/elements

[rugged adder]

Thanks! I appreciate the guidance on that 🙂

[oak ocean]

Also you should consider using Checkout and letting us do all of this for you 😉

[rugged adder]

I'd love that, at this point of my project I just need to get payments available and subscriptions managed. Ideally, I wouldn't be doing much work to get to the MVP lol

With Checkout, I couldn't find any easy way to implement the webhook to get / set customer data on my end (to enable / disable premium features).

[trail crypt]

Can you provide more detail about that? Checkout's Subscriptions fire the same events/webhooks as Subscriptions you create yourself.

[rugged adder]

Essentially, customers start as a free user, I offer the option to upgrade for $4 a month with a 15 day free trial. My ideal setup is to just direct them to the Checkout and all the busy work is handle by Stripe. Once they successfully complete a payment, my server sees the webhook request and then updates the DB.

I'm poking round this repo and it seems really close to what I need https://github.com/stripe-samples/checkout-single-subscription/tree/master/server/php/public

[trail crypt]

Yep, that's all possible with Checkout. Which specific step are you having an issue with?

[rugged adder]

I haven't began to implement Checkout yet, so I haven't ran into issues. However, if I can't figure out the Elements subscription stuff in the next 24 hours, I may switch to Checkout.

[trail crypt]

Gotcha. If you need any help let us know!

[rugged adder]

Thanks! Will do 🙂

[trail crypt]

Checkout is going to be a lot easier though, so you might want to start there instead of the other way around. 🙂

[rugged adder]

Decided to spin up a new branch attempting the Checkout route using the code guide from the above repo. Thanks for the suggestion. I'll open this back up if I run into issues

[trail crypt]

Sounds good! If this thread is archived when you come back feel free to ask in #dev-help!

[rugged adder]

Is the Stripe CLI tool available for the MacOS M1?

[trail crypt]

Yes, as far as I know it works fine on M1 Macs.

[rugged adder]

I appreciate the suggestion to go with Checkout. I've been able to do everything I needed in just a few hours. SUPER thanks, will give a tweet to the team in support if the help 🙂