#jasontheadams - Payment Element
tranquil timber
Hello again! 🙂
That's correct, with the Payment Element confirmations happen client side. Are the webhooks an issue for you?
exotic gazelle
Not necessarily. We use Stripe in a donation flow. So the donor will click "Donate", it runs through Stripe, and then we display a donation receipt. We'll just have to mark the donation as "pending" in the receipt, since we very likely won't know by then.
On the upside, not having the server exchange will speed up the donation for the donor.
tranquil timber
One thing you can do is include the Payment Intent ID in the return_url you specify when you call stripe.confirmPayment. Then, when the return_url page loads you can fetch the Payment Intent server-side, check its status, and render the page based on that.
You're taking donations so there's no fulfillment, but if there was I would caution you to not rely on this process for fulfillment as people can successfully pay and then drop off before visiting your return_url (meaning webhooks would still normally be required/recommended), but for your use case I think this would be fine on its own.
exotic gazelle
The whole process happens as a single flow on the front-end in a little donation box. The user isn't redirected at any point. Still, we could check it when it's time to display the receipt. I suspect some of the time the webhook will have come in by then.
tranquil timber
When using the Payment Element a redirect is required, you must specify a return_url.
exotic gazelle
Oh, I hadn't noticed that. It looks like that is only used if necessary though, right? Such as 3DS?
tranquil timber
3D Secure itself usually doesn't require a redirect, but many payment methods do, and more and more payment flows are moving to async processes that will require redirects in the future. As a result the Payment Element redirects by default for every payment method.
You can redirect only if required by passing a special property, but we do not recommend doing this, as it increases the complexity of the integration and provides a less consistent experience for your customers, especially as you adopt new methods of payment in the future. https://stripe.com/docs/js/payment_intents/confirm_payment#confirm_payment_intent-options-redirect
exotic gazelle
Interesting. Ok, that's fine. Does Stripe have a place to demo out the flow? There's this page, but there doesn't seem to be the ability to actually submit the payment: https://stripe.com/docs/payments/payment-element
tranquil timber
I don't think we have a full demo online yet, but let me confirm...
Ah, here we go: https://stripe-tinydemos-payment-element.glitch.me/
exotic gazelle
Oh, interesting, so the user doesn't even necessarily see a separate UI.
tranquil timber
Yeah. They might be redirected to, for example, their bank to approve the payment or something like that (depending on the method of payment), but at the end they're sent back to the return_url you specify.
exotic gazelle
Got it. I have to say, for Stripe's shtick being on-site payment experience for years, it's pretty odd that they recently decided a page flash is alright. I'm sure it's necessary for some reason.
Anyway, I believe my question is answered. I have another, unrelated, question. Should I ask here or start a new thread?
tranquil timber
Here is fine!
exotic gazelle
This is related to the publishable key stuff from yesterday — which seems to have worked, by the way!
When a customer connects to their account and we provide our Client ID to Stripe, are the subsequent tokens tied to our platform account? We just want to make sure that the publishable key changes won't somehow mean we don't get credit for the charges — for partner sharing and platform fees.
tranquil timber
Awesome to hear the publishable key stuff worked!
When a customer connects to their account and we provide our Client ID to Stripe, are the subsequent tokens tied to our platform account?
Meaning the secret and publishable API keys you get during OAuth? If so, yes, those are tied to your platform specifically.
exotic gazelle
Yup! Perfect! Thank you!
If it's identified via the token and key, what's the setAppInfo for? https://stripe.com/docs/building-plugins#setappinfo
tranquil timber
setAppInfo is used to identity the specific app being used. So, for example, if you're developing a plugin called "Super Amazing Plugin" you might set your app info name to Super Amazing Plugin, the version to 1.2.3, and the url to https://super-amazing-plugin.example.
If you made two different plugins that a single user could install separately they might use the same API keys but it's really useful to identify which specific plugin (and which specific version of those plugins) each API request comes from.
exotic gazelle
Got it. It looks like that's how we get our partner revenue sharing, right?
tranquil timber
I think that's tied to the partner ID, but honestly I don't know much about that.
exotic gazelle
Yeah, I think so. Ok, I think this is my takeaway:
- The application ties together multiple plugins (or whatever) to a single Stripe App, which likely has to do with partner sharing.
- The connect flow generates a token and key that are tied platform account. This is used for things such as the platform fee.
This seem correct?
tranquil timber
Yep. To clarify, though, the platform fee is defined in the API for each transaction. The key identifies the platform and, thus, where that fee goes.
queen pond
@exotic gazelle hello again! I'm stepping in and catching up, let me know if you have qs
exotic gazelle
Right. I'm referring how Stripe knows which platform the fee is identified with.
queen pond
are you asking "how would I know an ApplicationFee on a payment_intent.succeeded event belongs to me, vs another Platform"?
am I interpreting that right?