fox32_best-practices

[unborn elm]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1351559833605898311

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[pulsar creek]

I noticed that a payment method for paypal actually has a different email set that I can't control:

{
  "id": "…",
  "object": "payment_method",
  "allow_redisplay": "unspecified",
  "billing_details": {
    "address": {
      "city": "Lübeck",
      "country": "DE",
      "line1": "Sadowastraße",
      "line2": null,
      "postal_code": "23554",
      "state": ""
    },
    "email": null,
    "name": "asdasd",
    "phone": null
  },
  "created": 1742306227,
  "customer": "cus_RmfdRejuqQ4TAM",
  "livemode": false,
  "metadata": {},
  "paypal": {
    "country": "FR",
    "payer_email": "[e-mail]",
    "payer_id": "CLHTFL45WBSGP"
  },
  "type": "paypal"
}

I tried to do

stripe payment_methods update pm_1R40djFd6EDIZfQWlw5aHAF1 -d paypal[payer_email]="[e-mail]"

and

stripe payment_methods update pm_1R40djFd6EDIZfQWlw5aHAF1 -d billing_details[email]="[e-mail]"
```
but both operations fail ("Received unknown parameter: paypal" and "PaymentMethods of type paypal cannot be updated at this time.")

[undone ginkgo]

Hello, looking in to this. Also one quick question about using a setup intent first, is that because you have a trial or period of other non-payment upfront? If there is payment upfront for the subscription, the subscription's payment intents can also save cards while setting them up for future usage, so it can be simpler to just use them

[pulsar creek]

We always do the first payment when the subscription is set up, so the first payment should happen immediately. We might later change the amount/subscription and thought off_session is required in that case. Do you mean that we actually don't need to perform off_session in our case?

[undone ginkgo]

To be clear, the initial amount that they pay on the subscription might change, or an amount for a later charge when renewing? If you know the initial amount and are charging it immediately, using the PaymentIntent is definitely the way to go.

Do you mean that we actually don't need to perform off_session in our case?
The payment intent will have setup_future_usage: 'off_session' set, which tells us to save it in a way that prepares it to be used for future off session payments like the subscription cycling.

Also re: your initial question, from my testing just now it looks like that email will fail when being used on a payment intent, but not a setup intent. Our doc does mention "capturing or authorising payments" as the thing that will fail, so that may be expected behavior. Trying to get more clarification

[pulsar creek]

The amount can change when renewing, e.g. when we do price changes. Or the customer later adds additional products into the subscription. That usually happens online - expect our customer support does it for him. But we know the initial charge at the time we create the subscription while the user is online.

So you probably want say that once I did an initial payment intent with setup_future_usage: off_session I can get the same behavior to work? Interesting feedback, I will read a bit into payment intents in the docs.

Thanks for clarifing that these test data might only work with payment intents. That might already be helpful for me to dig a bit deeper into using them. Thanks!

[undone ginkgo]

Exactly, we have these doc sthat shows that flow. You create a subscription, and confirm the payment intent on its first invoice. That should properly set things up so that the PM gets charged for recurring payments going forward. And then when you change the price on the subscription, you can just update the subscription. PaymentIntents and SetupIntents do the same setup with the right configuration, so that same kind of change is possible after setting up your subscription with either.
https://docs.stripe.com/billing/subscriptions/build-subscriptions?platform=web&ui=elements
https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription

[pulsar creek]

I will experiment a bit and check whether my initial questions might go away that way 👍 Thank you!

Just one additional question, which flow would I use if I later want to give the customer an option to change the payment details while he is in an active subscription? Right now we are using a setup intent for that. Would we continue to use it in that case?

[undone ginkgo]

Yeah SetupIntent is good for that, you can save the PM with a setup intent and then update the subscription or customer so that that is their default PM. The rule of thumb is that if they are entering their details to make a payment immediately you should use a payment intent, but if they are doing it to be charged later when they aren't around you use a setup intent.