#ekarma
urban tinsel
Hello 👋
Can you elaborate a bit on both the questions just so that I can make sure I understand what you're blocked on?
valid hinge
Sure. Lets start with my first consideration, which is how far I can extend and customize the 'Checkout' module.
Currently, the only integration I have is a server-side call to stripe.checkout.sessions where I pass an array of products to checkout.
This works for the most basic UI/UX, however my project ideally involves substantial customization.
- I need to associate an email input form with the info gathered to serve as a primary key to connect all the data / decisions given during the checkout process
- PaymentIntent storage of 1 type of payment, and PaymentSetup for execution of the order not until a later date, when the customers product is ready to ship (enabled by my customers admin and executed by the customers admin or the customers customer)
- UPS API interaction to add a cost and shipping-time estimate. I need the bill/shipping info in advance to process this. Is Multi-step process w/ 'Address' Elements widget the way here?
- Inclusion of additional product cost (that we set) based on the payment method chosen
- Coupon integration for specials
Regarding Data modeling, any data I create through stripes entities (products, customers, etc.) will be a duplicate record i'd have to sync with my own database. Since this is the case minimizing or optimizing how and what I go about creating / updating.
All records stored across all of my DB models will have a 'id' property that is a UUID.
In an ideal world, I would minimize what I have to store and calculate through Stripes system.
2A. Can / should I pass that ID to stripe to use as an unique ID?
2B. My primary confusion regarding the data modeling, is what data types & records MUST i create through stripe, and how best can I simplify this / avoid duplication as much as possible?
2C. All your documentation seems to focus mainly on use-cases that are often times not optimal for someone like me, who is fully 'Custom' and not looking to adopt or integrate with any of the other services that are an additional percentage in cost, such as billing, tax, etc.
urban tinsel
Gotcha.
For question 1.
Yes. Elements + PaymentIntents API would be the way to go here. Given you need to control the timing of transferring the amount to the connected account, Separate charges and transfers might be a better option than destination charges (if there is more than 1 destination you need to transfer to)
Yes you can use Address Element to collect the addresses
The only limitation here would the usage of coupons, PaymentIntents API doesn't have support for coupons/promo codes. You'll need to handle that manually by looking at the discount amount and updating the PaymentIntent amount accordingly
valid hinge
So clarity to your Q1 comment, when my customers customer is checking out, the order and transaction should not be submitted when they 'submit'. Ideally, we store their order request associated to an email, with their payment info thats valid.
Later, they are ready to execute the order, the customer either enables it for completion, or finalizes teh order. At that time, is when the transaction should occur, and also when the destination payment initiates.
I was under the assumption to do this, payment intent enables storage of the payment methods, and setup intent might be used to pause the execution..
urban tinsel
SetupIntents allow you to store the PaymentMethod for later use where the customer doesn't need to be present during the Payment flow.
valid hinge
Ok, thanks, so lets start at a high level and then drill down... You have a good idea about all the customization i'll likely need to be able to execute on. Is using 'Checkout' going to still make sense? or will me trying to apply advanced use case customizations to 'Checkout' make me wish I had gone with a different approach
urban pythonBOT
valid hinge
It seems like I could use 'multi-step' + 'elements' + 'checkout' to support my use cases, but haven't gotten that confirmed from a dev.
urban tinsel
what exactly does "multi-step" mean in Stripe context? Are there any guides you're looking at?
Stripe Checkout is a Stripe hosted payment solution that's pretty robust in terms of supporting common payment flows. However, if you need granular control then it would be safer to go with custom Payment flow using Elements + Intents APIs
valid hinge
Quote from support "You might be looking for a two-step confirmation here[4]. There is no storage time limit for payment methods created."
4. https://stripe.com/docs/payments/build-a-two-step-confirmation
It appeared as though this enables you to break up the flow into steps, where I can add flow control to the logic and necessary functions
urban tinsel
Correct, but that flow is only supported by Elements + Intents API
Stripe Checkout doesn't support that.
valid hinge
Ok, good to know. So onto the second concern, which is data modeling.. Have you had time to look over the info I shared on that? (items w/ a #2)
urban tinsel
For 2/
It mostly depends on your preference. Intents API doesn't have support for "Products/Prices as line items". So you can just keep using your current DB models on your end.
You can just choose to pass the total amount of the product your customer is buying and handle "cart"/"order" on your end entirely
valid hinge
Ok, so if facilitating payments, storing my customers customers payment methods / details, minimizing PCI requirements and minimizing external data dependency was the goal..
-what is the minimum stripe needs stored on your end (entity types) for my use-cases?
-what API endpoints should I be targeting or primarily using?
it seems that I inevitably will have at least some data types and records that need to exist on your end as well as mine. Where can I learn more about best practices for this architecturally?
urban tinsel
You can store PaymentMethod and customer information on Stripe.
You'd be tokenizing the PaymentMethods client-side using Elements + SetupIntents API. This doc walks you through how you can set that up
https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements
Once setup, you can charge the PaymentMethod anytime afterwards by using the PaymentIntents API
https://stripe.com/docs/api/payment_intents
https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements#charge-saved-payment-method
Since you'll be using connect, you'd want to refer to destination charges or Separate Charges and Transfers docs instead.
https://stripe.com/docs/connect/destination-charges
https://stripe.com/docs/connect/separate-charges-and-transfers
it seems that I inevitably will have at least some data types and records that need to exist on your end as well as mine. Where can I learn more about best practices for this architecturally?
I don't think we have a doc/guide for that unfortunately as it varies from integration to integration.
valid hinge
Thanks for this info, thats very helpful.
So can you expand on what Stripe support might have been alluding to with this comment? "There are unique identifier IDs for each object that would be stored within Stripe". Im quite familiar with the idea of a primary-key, just not sure if he was suggesitng something more specific
Can you share what you find as the most (or examples youve seen) popular data mgmt approach for my situation? i.e. storing the unique IDs for a record of a stripe object as a property value on the related object in my system
urban tinsel
"There are unique identifier IDs for each object that would be stored within Stripe"
I think it mostly refers to the IDs of the stripe objects.
Each object on stripe would have unique ID
For example,
https://stripe.com/docs/api/customers/object#customer_object-id
This is something you'd need on your end so that you can easily track purchases and all
caching certain object IDs in your DB would allow you to avoid hitting Stripe APIs on each transaction
It will mostly come down to how you're currently modeling your DB
valid hinge
right. So lets assume my customer requests a payout through my platofrm.. would a typical flow for me be something like...
-Software triggers stripe API
-Stripe triggers the webhook event that I listen for
-I pass associated data from webhook event into a side-effect that updates records on my system
urban tinsel
Yup, sounds about right
valid hinge
"caching certain object IDs in your DB would allow you to avoid hitting Stripe APIs on each transaction"
if I stored the customer ID, wouldn't that just give me the parameter to return the customer object data with an API call? Not sure how it would minimize Stripe API interaction
perhaps it becomes a 1 API call operation, instead of 2-3?
urban tinsel
if I stored the customer ID, wouldn't that just give me the parameter to return the customer object data with an API call? Not sure how it would minimize Stripe API interaction
perhaps it becomes a 1 API call operation, instead of 2-3?
Yes, it mostly comes down to what objects you store and how you use it.
valid hinge
Ok. I'll likely encounter issues as I go through this, would this thread be the place to come back to?
urban tinsel
We typically auto close idle threads but you can always open up a new one when you need help
valid hinge
The part where I struggle the most, is inability to filter documentation instructions to my use case. Knowing how to do something 10 diff ways has value but any advice on how to better navigate the docs?
For example Customer. In my use case I’m building a flow for my customers customers. Does stripe need to know that nested relationship insight? Are both customers?
glossy wadi
Hi 👋
I'm taking over as @urban tinsel needs to go
valid hinge
Hello, thank you.
glossy wadi
I'm not sure what you are describing here.
For example Customer. In my use case I’m building a flow for my customers customers. Does stripe need to know that nested relationship insight? Are both customers?
valid hinge
My situation is a Custom Connect Platform setup using destination payments.
Need more?
LVL1 customer is who I split the payment proceeds with, LVL2 customer is who pays for the order from LVL1 store
glossy wadi
OKay the LVL1 customer is a Connected Account
LVL2 customer is a Customer
Since you are using destination charges the Customer object will be saved on your platform account
valid hinge
Ok, so does stripe care about the difference between that 'Customer' being nested to my connected account? or do they all nest to me?
glossy wadi
As I said, these customers will belong to your platform account. because that is what is required for destination charges. If they get saved to the Connected Account you will not be able to charge them
valid hinge
Ok, good to know. So Stripe would never know the relational insights of 'customers' in relation to my 'connected' accounts
glossy wadi
There isn't one as far as Stripe is concerned. The Payments also exist on your platform account.
valid hinge
Right, I can handle things on my end, just trying to familiarize w/ best way to engage Stripe.
So this is a summary of my desired flow.
I'll use Setup intents API (Step 2) to setup the payment for later
Ill use destination-charges (guide from link) to execute the transaction when its time
What I am slightly not sure about is what to do about storing the customer payment card type & details.. Is this Payment Intents API? Any link you could share, ideally specific to my use-case?
glossy wadi
storing the customer payment card type & details
Have you tested out a basic flow for this?
It's pretty straight forward when you use Setup Intents with a Customer ID
The payment method details get saved to the Customer as a Payment Method object
valid hinge
Not yet. Right now I just had a simple 'Checkout' integration setup. I have learned that isn't ideal and so now i'm migrating to what we're discussing.
Ok, so are you saying the 'SetupIntents' flow / api covers all of what i'd need from step 1?
glossy wadi
I think you should read through this integration doc to get a sense for what this approach will provide you: https://stripe.com/docs/payments/save-and-reuse
valid hinge
Ok, I think I should have what I need now. One last item... I applied for this Beta.. https://stripe.com/docs/connect/get-started-connect-embedded-components
Any idea how long before a decision is made? I would hate to have to redo my implementation days after it was first built
glossy wadi
Unfortunately I have no insights into that.
valid hinge
Any clue if its mostly complimentary to what we've discussed? Seems like its tailored more to backend platform functionality instead of checkout based flows
urban pythonBOT
glossy wadi
I've just been talking about saving customers and payment methods. From what limited information I have, these components are focused on allowing platforms to build their own Stripe-style dashboards for their Connected Accounts.
So it may be something you want to do but it isn't directly related to what we have been discussing
valid hinge
yea it seems complimentary. Thats all I had, thanks for your help!
glossy wadi
Happy to shed what 💡 I can 🙂
valid hinge
sorry just discovered one last question..
The SetupIntent guide doenst mention Destination Charges, and the Destination Charges guide doesnt mention SetupIntents. Am I missing the guide or instruction as to how I calculate & process the platform fee through (or after) SetupIntent?
cyan grotto
Hello! I'm taking over and catching up...
Setup Intents don't have any amount, they're only used to set up Payment Methods for future use, so there's no platform fee associated with them. You would, for example, set the application_fee on the Payment Intents later.
valid hinge
Ok, i'll walk you through what I was planning and let me know if i'm on the right track, or what i'm getting wrong..
This is the integration flow I was about to begin development with through SetupPayments & PaymentIntents API based on the docs.
STEP 1 BEGINS:
SETUP-INTENT -> after gathering users email, I create customer in stripe
SETUP-INTENT -> create SetupIntent
SETUP-INTENT-> collect payment details
SETUP-INTENT -> enable faster checkout with Link
SETUP-INTENT -> submit the payment details to Stripe
STEP 2:
PAYMENT-INTENT -> initiate charge after all calculations are done with Destination payment accounted for?
SETUP-INTENT-> charge the saved payment method later?
Does this order of events seem right? seems both would be necessary, and them communicating together is required
cyan grotto
Not sure what the "SETUP-INTENT" and "PAYMENT-INTENT" prefixes mean in that flow, can you explain?
valid hinge
The Stripe API I'd be engaging with to achieve that step
I adjusted the text. "Step 1" & "Step 2" correspond to hte flow I shared above.
Step 1 would iniitate when the user enters the 'checkout' flow after adding products to their cart.
Step 2 would be manually triggered at a later date by my Connected account
cyan grotto
Ah, gotcha. So a Setup Intent is only used in the beginning, to set up a Payment Method for future use without taking payment at that time. You wouldn't use a Setup Intent on the same Payment Method again later.
Step 2 only needs the Payment Intent.
valid hinge
Ok, so even though SetupIntent CAN charge a saved payment method, i'd look to do Step 2 (Charging) through Payment-Intent
so for my use-case I wouldn't even need to initiate the PaymentIntent until Step2, correct?
Is there any documentation that discusses how to execute a PaymentIntent charge based on an existing SetupIntent object? Couldn't find any about how those 2 pass info
cyan grotto
Ok, so even though SetupIntent CAN charge a saved payment method
It can't. Setup Intents do not charge money.
Setup Intents are only used to set up a Payment Method for future use. You create a Setup Intent, confirm it, and the associated Payment Method is then set up. After that the Setup Intent is not used again, and you don't create any other Setup Intents for that Payment Method. When it comes time to charge the Payment Method you use a Payment Intent for that.
valid hinge
Ok, I may have misread the doc. I think I now understand, let me reconfirm..
-
SetupIntent for all of Step 1 - guide = https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements
Net result as far as Stripe is concerned,
-Customer Created
-PaymentMethod attached to said Customer- type (CC/Debit or ACH) with valid inputs (card / bank info). -
PaymentIntent for all of Step 2 =
-I pass all stored order details and calculations both from my db and from step 1.
-I pass customer id from step 1 to 'customer' property of PaymentIntent
-Follow remaining steps from destination charge guide https://stripe.com/docs/connect/destination-charges
cyan grotto
Yep, You also specify the Payment Method ID along with the Customer ID on the Payment Intent.
valid hinge
Great, thanks. Very helpful to know. I plan to offer ACH as a method.. would it then take 2-3 days or so before we knew if that was 'valid' similar to a Credit Card?
cyan grotto
Yeah, ACH takes a few business days to go through.
valid hinge
so during Step 1, ideal would be just to store a valid method. So when you say "go through" are you referring to Payment submission during Step 2?
cyan grotto
Correct.
valid hinge
great, thanks for your help!
"Link" seems like exactly what i'd want.. but it appears to cost extra and require approval before using, is that correct?
cyan grotto
Link does not cost extra as far as I know, where are you seeing that?
Also not aware of it needing any kind of approval.
valid hinge
I saw a CTA labeled "Contact Sales"
Alright, looks like Link should fit in perfect w/ my goals for up front account info, doesn't appear paid only or approved only.. So i'd be using 3 'elements' (Link Authentication, Payment, and Address Elements) which occur as part of "Step 1".
cyan grotto
Sounds good!