benjamineugenewhite

[blissful ocean]

FWIW, the error I get in SPA when submitting PaymentElement form looks like this:

{
  "error": {
    "code": "resource_missing",
    "doc_url": "https://stripe.com/docs/error-codes/resource-missing",
    "message": "No such payment_intent: 'seti_1LzkovPbhdfvD1kVC4R4QBB1'",
    "param": "intent",
    "request_log_url": "https://dashboard.stripe.com/acct_1JhHQsPbhdfvD1kV/test/logs/req_NmSXrgHtbb1NZf?t=1667410585",
    "type": "invalid_request_error"
  }
}

[vital elm]

AH, okay. So it looks like you're trying to pass a Setup Intent ID to an endpoint that needs a Payment Intent ID

[blissful ocean]

Also of note, the value I'm getting back for client secret off pending_setup_intent is seti_1LzkovPbhdfvD1kVC4R4QBB1_secret_MjDFMq40co8lfaiziatxl005mKXz1qS, but looks like that's being truncated

I suppose I am!

How do i get a PI ID for a trialed subscription?

*or rather, how do i get a PI client secret?

[vital elm]

For context, when you create a Subscription that is trialing, Stripe automatically creates a zero-dollar ($0) Invoice and advances it to paid status. For this Invoice, there is no Payment Intent, since the amount of that first Invoice is 0.

What are you trying to do specifically?

[blissful ocean]

I'm just trying to confirm the payment from the front end.

await stripe.confirmPayment({
      elements,
      confirmParams: { return_url, payment_method_data: { billing_details: stripeBillingDetails } }
    });

And that's happening because I'm passing a bunk value for client_secret when first loading payment element.

[vital elm]

It's a trialing Subscription, so there wouldn't be a payment in that case. Do you simply want to create a Payment Method that can be used to charge the Subscription when payment eventually becomes due?

[blissful ocean]

yes, exactly that

more context: in our platform, we mark some transactions as "flagged", and in that case, we wan to go ahead and collect payment info, but we only want to charge if we unflag (in which case, we end trial on subscription, and which we reconcile before the trial end).

so we're not wed to trial_period to accomplish this. seems like it might also be possible to accomplish by doing something with billing_cycle_anchor.

[vital elm]

Got it, okay. So, without totally refactoring the whole Subscription system, you could just create a Payment Method for the Customer and set it up for future usage so that when the Subscription's trial ends and the payment is due, you'll have a Payment Method on file that can be charged automatically: https://stripe.com/docs/payments/save-and-reuse

The only caveat is that on Step 7 in that guide, rather than charge the Payment Method, you can just wait for the Subscription to be done trialing (or end the trial explicitly)

[blissful ocean]

Cool. Do I need to somehow point to the setup intent when creating the subscription?

[vital elm]

Nope! As long as the Customer has a valid Payment Method attached to them, you should be good to go. Depending on when the Payment Method is created (and if there is already one on file for that Customer) you may need to set the default Payment Method https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method

[blissful ocean]

I think this gets me pointed in right direction. Thanks!

[vital elm]

Sure thing!

[blissful ocean]

One more quick question -- instead of creating trialed subscription, could we just use the data captured via setup intent to create subscription and immediately charge for it when we unflag a transaction?

if I can avoid trialing, that's a win

[vital elm]

You wouldn't use a Setup Intent in that case. You would do the exact same thing I mentioned above to create a Payment Method and a Customer object, then authenticate that Payment Method and set it up for future usage. Once all of that was accomplished you could simply create a new Subscription at any point and charge them for it without using trials.