#JamesFroud - Subscription
lost knot
Okay, can you try to break out
- What the decided part(s) of your implementation are
and - Which process you have questions on?
It's kind of unclear exactly what the questions are vs the implementation details
dusk kiln
It's more implementation to be honest with accepting the payment online, we would like to accept, card, pay by invoice (outside of stripe) and direct debit. Looking at the best approach to take these payments.
lost knot
What do you mean when you say
pay by invoice (outside of stripe)
Is Stripe no longer going to be that part of the implementation?
And when you say
direct debit
what are you referring to?
dusk kiln
"What do you mean when you say
pay by invoice (outside of stripe)
Is Stripe no longer going to be that part of the implementation?" - I believe we may use Zero - but simplest form, is we get a payment by bank transfer to our bank, and I would mark the invoice as paid in Stripe.
Direct Debit - SEPA I believe it was called for the UK.
lost knot
Okay so what is Stripe's role in this?
You can certainly use Stripe to accept a payment method, create customers, and subscriptions
dusk kiln
Manage subscriptions and take recurring payments yearly.
I've had a couple of calls already with pre-sales and a Jumpstart call.
lost knot
Okay. So first here's the details on collecting and saving SEPA direct debit for future usage:
https://stripe.com/docs/payments/sepa-debit/set-up-payment
Unfortunately I'm not familiar with either of those teams or processes. My work at Stripe has been focused on getting developers unblocked in their integrations.
So then you've got a subscription with an annual price associated with it, yes?
Or a Monthly interval and billed every 12?
dusk kiln
A subscription with an annual price - composing of two or more products.
lost knot
Alright. And do you want to use a card to bill for this? Or are you going to focus on SEPA debit for your payment method?
dusk kiln
A card to bill for this - only for the first 3 months while we launch, then we will offer SEPA direct debit as well.
I see Setup Intents API used for SEPA direct debits, which leans me more towards perhaps I should use that for Card Payments, using the PaymentElement form. But I'm still concerned that the customer that creates the subscription is not the cardholder. Or perhaps the customer that is created should always be the cardholder, and get around it that way? Not so keen on that idea I think though. As there could be a case for multiple payment cards for a customer.
lost knot
Why would the customer not be the card holder?
And a single customer can have many associated payment methods without it being a problem
dusk kiln
That might be in our logic rather than yours. A HR person may want to buy a yearly subscription, but they are not authorised to pay for the subscription, so the logic on my side is that the HR person is the primary account holder for the subscription recorded in our system, allowing them access to our system. So I had used the HR person when creating a customer in Stripe, but the card holder might be someone in the company or might even want to use their personal card.
lost knot
Ah, okay. That clarifies things.
I'm spinning up my integration, I want to check if SEPA debit requests the billing details (like name on the card, address, etc.)
I think if you capture that you _should _ be okay to proceed with different card holder vs customer.
Okay I think the default SEPA debit interface (using the Stripe Payment Element) will capture enough information.
This is the interface I generated when testing it on my integration.
dusk kiln
I did use https://stripe.com/docs/js/elements_object/create_payment_element and passed a fields object
var paymentElement = elements.create('payment', {
fields: {
billingDetails: {
name: 'auto',
email: 'auto',
phone: 'auto',
address: { line1: 'auto',
line2: 'auto',
city: 'auto',
state: 'auto',
country: 'auto',
postalCode: 'auto'
}
}
}
});
But all I saw was Country, and PostalCode.
lost knot
What type of payment method were you using?
The create payment element takes a lot of it's cues from the Payment Intent or Setup Intent used to generate it.
dusk kiln
let elements = stripe.elements({ clientSecret: "xxxxx" });
var paymentElement = elements.create('payment', {
fields: {
billingDetails: {
name: 'auto',
email: 'auto',
phone: 'auto',
address: { line1: 'auto',
line2: 'auto',
city: 'auto',
state: 'auto',
country: 'auto',
postalCode: 'auto'
}
}
}
});
paymentElement.mount('#payment-element');
I passed the Setup Intent as the clientSecret.
lost knot
Yeah but this is configured to only provide card info.
As your code snippet shows, you can only specify 'auto', which still leaves the rendering of billing details up to our JS determining whether it's necessary or not.
dusk kiln
Ah I see...I'm using Laravel Cashier library, and it looks like it 'defaults' to card payment if you do not specify payment method types.
lost knot
But the issue I think you are worried about is card authentication
I don't think there is really any problem with one Customer object having a Payment Method associated where the actual card it represents belongs to another person.
It just means that the HR person (or whoever) may need to go find the card holder when the issuing bank wants to re-authenticate.
That would be something in your flow. This doc does a great job of discussing how payment methods work (with auth, recurring charges, etc.) with subscriptions.
https://stripe.com/docs/billing/subscriptions/overview