#masonhale-holding-fees
bronze owl
👋 Feel free to start listing the the options you'd come up with here!
^^ @reef vector
reef vector
(reposting to masonhale-holding-fees) Option #1, The most likely contender I see is a PaymentIntent with setup_future_usage: 'off_session' and setting the customer. This looks like it essentially keeps the "card on file" for that customer, and would hypothetically allow our app to make any future charges we want against that card. We would enforce the limit to the agreed upon volunteer penalty fee in our app logic. The downsides I see for this option are: (1) per the docs it may prompt for additional verification at checkout, (2) it requires a Stripe Customer object to be created, which is a step we weren't planning to do otherwise, (3) it adds risk because we have created an authorization that could potentially be used for a wider range of charges. Ideally, we'd like to limit the authorization to a pre-agreed amount to remove the risk of this saved card getting misused in any scenario.
Option #2, Mandate. https://stripe.com/docs/api/mandates/object The description of this as "a permission a user gives to debit their account" sounds spot on. But digging deeper, this feature is not mentioned elsewhere in the docs and as far as I can tell is intended to support a very specific use-case for Canadian bank debit cards. For that reason, I think this one is not a viable option, but I wanted to confirm my understanding.
Option #3, Capture Later/Place a hold on a card. https://stripe.com/docs/payments/capture-later -- this reserves the amount from the card credit limit for up to 7 days. The duration of this hold is not long enough to support our use case, and we don't really want to reserve the funds because most of the time people do meet their volunteer requirements -- thus this would be a too pessimistic option.
Option #4, SetupIntent -- https://stripe.com/docs/api/setup_intents -- link PaymentIntent with setup_future_usage: 'off_session', this appears to be a way to retain a card for future charges. But my read of SetupIntent is that it does so without any immediate charge. In our use-case there are nearly invariably immediate charges for the team registration fees. However, there are sometimes cases (due to discounts, etc.) where the immediate amount due for team registration is $0, but the conditional volunteer penalty fee would still apply. My read is that if I used PaymentIntent primarily, if the amount due at checkout was $0, I would need to use SetupIntent to capture the card info for the potential future volunteer penalty fee charge. Am I on the right track?
Option #5, Subscription - https://stripe.com/docs/api/subscriptions -- I could see a scenario where the penalty fee is setup as a Subscription for a specific amount within a specific timeframe, but with a recurrence of 1 time. And that 1 time might or might not be charged. This one seems less than ideal because the messaging to the user would suggest a recurring charge, which this would not be, and again the default behavior would be to execute the charge at the subscription interval. We want to instead require affirmative user action to collect a conditional volunteer penalty fee. If no action is take the fee should not be charged.
== END OF LIST ==
Okay, those are the options I've found. Did I miss any? My game plan is a combination of PaymentIntent (when there is an immediate amount due) combined with SetupIntent (where there is no immediate amount due). I am a little worried about some downsides for both, but I think those are the best options for my use case. What do you think?
bronze owl
That's a very comprehensive list, and I don't think you've missed any options - let me go through each of them and give some thoughts
To start off, I'd agree that you can go ahead and eliminate Option #3 - with the limited window and the fact that you don't want to authorize the charge until much later, this option doesn't sound like what you want
The general reason why your flow is difficult to model on top of our API is that you want to trigger a delayed charge - something that isn't well-represent by our regular payments.
I do think a combination of Payment Intents (Option 1) when initial payment is due and Setup Intents (Option 2) if nothing is due would be the best solution for you to save the payment information and then use the saved card at a later point to collect the fee. Yes, you are correct in that Payment Intents cannot be used if the initial amount due is $0 (which is when you would use Setup intents)
Subscriptions (option 5) is an interesting suggestion, and one I wouldn't have thought of - they have the benefit of being able to schedule the next charge way in advance, and you could set them to cancel at a specific date
reef vector
Thanks. And am I correct in my read that Mandate is not a fit for this use case?
My biggest beef with the Subscriptions approach is that I would be essentially "hacking" Subscriptions to fit this use case that it wasn't really designed for. As a result, I expect it to generate confusing messages to the user/payer and potentially the payee. Also, it would charge by default unless cancelled preemptively, which is not the behavior we want.
I should mention that the way we implemented this with our existing payment provider (WePay) is via a feature they provide for a "preapproval" -- I can prompt the payer to preapprove an amount $X and then I can issue multiple separate charges against that pre-approval, and those charges can be separated by up to 6 months. Therefore we get a preapproval for the amount due at registration + the volunteer penalty fee, but only issue a charge for the amount due today, retaining the preapproval balance for a potential future volunteer penalty charge.
At first I was hoping that a PaymentIntent would work the same way. I assumed one PaymentIntent could be used for multiple separate charges, and that those could be separated by time. But I don't see anything in the documentation to support this usage. Can a single PaymentIntent be used for multiple Charges?
As a newbie to Stripe, it appears to me that PaymentIntent is a new API that replaces an older Charge API, but that history is not 100% clear to me.
bronze owl
As a newbie to Stripe, it appears to me that PaymentIntent is a new API that replaces an older Charge API, but that history is not 100% clear to me.
Yup! This is true - Charges are our legacy payments API
My biggest beef with the Subscriptions approach is that I would be essentially "hacking" Subscriptions to fit this use case that it wasn't really designed for. As a result, I expect it to generate confusing messages to the user/payer and potentially the payee. Also, it would charge by default unless cancelled preemptively, which is not the behavior we want.
Yeah, your use case isn't a perfect conceptual fit for your use case and if messaging is important to your users then I'd agree that Subscriptions isn't the behavior you'd want.
At first I was hoping that a PaymentIntent would work the same way. I assumed one PaymentIntent could be used for multiple separate charges, and that those could be separated by time. But I don't see anything in the documentation to support this usage. Can a single PaymentIntent be used for multiple Charges?
A single Payment Intent cannot be used for multiple charges
reef vector
Ok thanks so much for your clarifications @bronze owl! This confirms my plan to use a PaymentIntent + SetupIntent combo to cover the no $ due at checkout scenario. Unless I missed the point of Mandate?
bronze owl
And am I correct in my read that Mandate is not a fit for this use case?
Mandates are something specific to certain payment method types (mostly bank debits ones https://stripe.com/docs/payments/bank-debits). I'm not the most experience with Mandates but from my understanding not all of them allow for that level of customization, and don't allow you to specify an actual amount that you want to pre-authorize. They focus more on the interval/general agreement for when payment will be taken
reef vector
Ok, I'll scratch Mandates of my list and proceed with PaymentIntent + SetupIntent as described.
Thanks again!
bronze owl
👍 happy to help!
@reef vector Feel free to keep using this thread if you have other questions!
Copying your question here:
New question: I'm working on a Stripe Connect Express integration. All transactions displayed on the customer-facing (lite) Express dashboard are labeled "Payment from [my app name]" -- given the nature our app, most of these transactions will be for identical amounts, which makes this listing pretty useless. I have set both the description and statement_descriptor to something more immediately identifiable when creating the associated PaymentIntent, hoping that would affect the transaction description on the Express dashboard, but in my testing that has not been the case. No matter what I do, every transaction is listed as "Payment from [my app name]". Is there a setting I'm missing? Is there any way to change how transactions are listed in the Express dashboard?
Let me look into this - haven't looked at the Express dashboard in a bit
reef vector
New question: during the Connect Express Account setup flow, when I'm testing (using a test mode API key), I am prompted to provide a full 9-digit SSN. However the documentation indicates only the last 4 digits of the SSN (representative.ssn_last_4) will be requested. In addition, when I setup an account on the example https://rocketrides.io site, only the last 4 SSN is requested. Knowing that users are generally reluctant to provide a full SSN unless they absolutely have to, I expect the requirement a full SSN in account setup will result in a meaningful drop in account setup completion, and prompt more worried support requests, relative to a request for a last-4 digit SSN. Do you happen to know when/why a full SSN is being required in this case, which is in conflict with the documentation?
bronze owl
Starting with your first question - do you mind sending a screenshot of what you're seeing? Or a specific payment intent ID that I can take a look at?
reef vector
Sure. Here's a link to the receipt URL for the payment in question (showing the description): https://pay.stripe.com/receipts/acct_1033xW2J1KLBnsI8/ch_3KF3NC2J1KLBnsI80h0jxLlh/rcpt_KutCYybdAa0i56LuCoJWKPN5yadrlNw -- screenshot and PaymentIntent ID coming next.
Screenshot of my dashboard:
The same behavior shows up in the RocketRides.io dashboard too (which I take as a discouraging sign)
bronze owl
Ah, I think this is a limitation of the dashboard - since the funds are being transferred to the express account from the platform, we populate it with the name of the platform account
reef vector
Follow-up to previous PaymentIntent question: I ran across the documentation that suggested to me that a PaymentIntent can capture multiple charges. The PaymentIntent has a charges attribute that is a list, and is documented as "Charges that were created by this PaymentIntent, if any." -- this suggests a PaymentIntent can be used to trigger multiple charges, no? If the not for the use case I describes (multiple charges over time), how would one end up with multiple charges attached to a PaymentIntent? [Just trying to clarify my understanding, and explain my previous confusion.]
@bronze owl I'll just accept the transaction description as a limitation of the Stripe Express dashboard. Is there a channel I can use to convey that this very limited/repetitive description makes the dashboard useless for my customers?
bronze owl
That's a weird quirk of our API - you can have more than one charge intent tied to a payment intent if there were failures, but you'll only ever have a single successful one
And I can relay that as feedback if you'd like me to!
I need to head out soon (one of my teammates will hop in) but I wanted to quickly address your question on SSNs - there are a number of factors that go into whether we need full SSN or just the last 4. It's likely that there's something specific about your platform that differs from the rocket ride example that is requiring the full SSN
reef vector
Ok, thanks for the clarification @bronze owl . I would love to learn if there is any change I can make to relax that to last 4 SSN instead!
bronze owl
I'm not sure of all the requirements that go into that, but I'd recommend writing into support (https://support.stripe.com/contact) they'll be able to look at the specific requirements of your account and pinpoint why your connect accounts are asking for it
reef vector
Ok, will do!
bronze owl
👍 If you need anything else @cloud drift or @glass patrol will be able to help here!