#adam-sct-checkout
1 messages ยท Page 1 of 1 (latest)
So you say "to the Checkout" so I thought you used our Checkout product but then you show code where you create the PaymentIntent yourself.
Are you using Checkout or not?
Oops not Checkout, I was following PaymentIntent from this https://stripe.com/docs/connect/charges-transfers#transfer-options
Okay, so which part are you curious about, I'm not sure I understand. You control that part of the code and the loop and it's not really Stripe-specific
though usually you shouldn't trust that information from the client as it's unsafe and anyone could modify it
We're basically hoping the transfers allow us to create as many transfers as there are sellers involved in the transaction. Like if Amazon or Etsy needed to distribute transfers to each Seller involved in the customer's Cart Purchase
Oh the SellerIDs will come from an object that is linked to their Stripe AccountLink, is this what youre talking about?
not really
Sorry I'm just confused by the question
But yes you can create 1, 2, 20, 4000 transfers, it's all supported
Note that the way you approach this you are floating the funds entirely from your own balance
See https://stripe.com/docs/connect/charges-transfers#transfer-availability for more details
Sorry was just checking to see if the team thinks the transfer function supports varying numbers of transfers to occur per transaction, e.g. an Etsy customer could buy from 1-10 sellers depending on Cart size/variety
ah Transfer availability, does this allow your Stripe account to go (-negative) in value?
nope
but really you want the flow I just linked you to
almost no business wants to "float the funds". You're unlikely to charge me $1000 today, and then immediately pay $900 to an etsy seller out of your own company's money and then wait 2 days to get the $1000 back from the banking network
almost everyone wants the funds to be released together so you basically want source_transaction: 'ch_123' in this flow (what I linked you to) but it still works the same beyond that
Okay we'll read up more on source transactions and floating
Its probably not feasible to use Destination Charges to our platform account right and then Transfer to each connected account manually?
Especially since you can only have 1 destination for Destination charges
@hasty lava ๐
so no Destination Charges create the Transfer immediately, what you described here
Its probably not feasible to use Destination Charges to our platform account right and then Transfer to each connected account manually?
that is Separate Charges & Transfers
And with only 1 destination allowed?
Oh wait Separate Charges... allows for many destinations
But Destination charges only supports 1 destination..?
yes
Destination supports only 1 destination acct
and Separate Charges & Transfers supports n destinations
Okay, and its not scalable to manually payout connected accounts from our Platform Dashboard so I guess we'll continue with Sep Chg Tfr
just going to read on Source Transactions really quick
Can these Stripe paymentIntent's be maybe integrated with Spreedly's Apple Pay?
We don't know anything about Spreedly so you'd have to ask them directly what their API supports
Okay, I was just referring to prev threads, Apple Pay is available on Safari, but would it work on an iOS app and Android app?
Apple Pay never works in Android. And yes it works in an iOS app if you integrate it
We're publishing ReactJS code to iOS and Android stores. Think apple pay/google pay will still work? We've seen paymentIntents work so far on iOS and Android, but not Transfers or apple/android pay yet,
I'm honestly confused by the ask
what does "Not transfers" have to do with mobile?
Transfer creation always has to happen server-side where you safely use your Secret API key
Unfortunately, I'm not sure what you're calling "we're publishing ReactJS code" and how your integration is built overall
yes Apple Pay works on iOS devices in Mobile Safari, whether you write vanilla JS or React or other frameworks
same for Android + Chrome
but you also mentioned Spreedly on top of it (which has their own integration separate from Stripe as far as I know)
Oh I dont know, gotcha, yes. I think Google Signin has not worked on iOS, although I dont remember if thats server side or not
google signin has nothing to do with Stripe or server-side
you've lost me completely ๐
i only mentioned Spreedly because we wanted Apple/Android pay,
what does Spreedly have to do with Apple/Android pay?
Spreedly is a "card vault" that aggregates numerous payment processors such as Stripe or Braintree
Ill have to check ๐คฃ
Okay, we only briefly looked into it, it seemed like they offered Apple Pay. I read in a previous thread that Apple Pay may not be available on certain integrations
yeah it makes no sense to use Spreedly just for Apple and Google Pay ๐
like Stripe supports it, if you don't use Spreedly in general, please don't use them just for mobile wallets it'll make your integration extremely complex
we support this already for you https://stripe.com/docs/stripe-js/elements/payment-request-button
we wanted to make sure it can work in the App also, downloaded from App Store
yeah I worry you're mixing up a lot of things right now all mushed together
but yes Apple Pay works in iOS apps, either written straight in Swift of Objective C or with a webview + JS
same for Google Pay / Android / Chrome
Yes we just wanted to take a short break from the for loops and objects and re-evaluate our design of all this,
sounds good