#rocketoclimber

1 messages · Page 1 of 1 (latest)

brazen portalBOT
frozen scaffold
#

Hmm, why specifically do you need to upgrade API versions to support Link? That shouldn't be necessary

#

But otherwise, what you're describing isn't really possible with strongly typed SDKs like the Golang one

#

Each major version is fixed to a specific version and with it potentially breaking changes. I guess in your multi-tenant environment the only way to handle that is to have multiple SDK clients to handle the integration dependent on their API version

echo sequoia
#

😫

#

Ok

frozen scaffold
#

Be curious to hear what is forcing you to constantly upgrade API versions

brazen portalBOT
echo sequoia
#

From my understanding, the Golang SDK is always on the latest version of your API (it auto-updates if I understand correctly). As a result, at each API release we must tweak our integration and ask our clients to upgrade their API Keys to the latest version.

#

Also, if what I'm stating is correct. We shouldn't be able to handle multiple SDKs aslong as we are in Golang

slow minnow
#

Hi! I'm taking over this thread.

#

Give me a few minutes to catchup.

wanton spindle
#

For context, why do your clients call Stripe directly? Are those independent businesses or are they all interconnected via your platform? It would then make more sense for them to call your platform, which in turn calls Stripe. Then you would only need to manage the API version and SDK in one place.

echo sequoia
#

All interconnected via our plataform, but each creates its own API credentials in Stripe and then sets them up in our plataform

wanton spindle
#

Are you using Stripe Connect?

echo sequoia
#

(Just went into a meeting, will get back at you shortly)

wanton spindle
#

In case I need to disconnect by then, I advice you to look into Stripe Connect, if you haven't already. This way you can create and manage multiple Stripe Accounts and ultimately not have them interact with Stripe directly. You would fully own the Stripe relationship and your clients will only communicate with you. This way you would also avoid your initial SDK/API version issue.
https://stripe.com/docs/connect

echo sequoia
#

I'm back

#

Thanks for the tips. Unfortunately, working like that is not an option for us. Our clients are enterprise retailers (we got 100+), and they need to own the relationship with their PSPs. Our solution represents only one Sales Channel, among multiple ones

#

In our solution we allow our clients to configure connection to various PSPs, including Stripe, and we then communicate with the PSPs in their behalf to process in-store payments (through POS or pay by link)

#

Our clients are quite interested in Stripe, but the high maintenance requirement of updating API versions risks adding friction on the use of your solution

#

(For even more context, as my fist message might be misleading, we are an Order Management Solution which features and Order in Store app that our clients can deploy in their store to expand their points of sales)

thorny crown
#

👋 taking over for my colleague. Let me catch up.

#

Thanks for the tips. Unfortunately, working like that is not an option for us. Our clients are enterprise retailers (we got 100+), and they need to own the relationship with their PSPs. Our solution represents only one Sales Channel, among multiple ones
If you're using Direct Charges they will

echo sequoia
#

Heum, very interesting. If we use direct charges we will be able to handle API versions on our side independent of the API version set on our clients side ? For example, they will be able to handle transactions in the ecommerce with API version A and we will be able to handle payments through connect using API version B.

thorny crown
#

yes

#

you can always use explicit API versions with every API request

echo sequoia
#

Not if using the Golang SDK no ?

thorny crown
#

with the Golang SDK, each major version is tightly-coupled with an API version

#

but this means that each request going out of that SDK is explicitly specifying an API version

echo sequoia
#

If so, why is it that when you made your update of v75 if a client created fresh credentials they wouldn't work with our current integration v74 ? What I struggle to understand is why if the API version is specified on the requests it blocks.

For example

Client A, creates credentials on 09-2023
Client B, creates credentials on 11-2023

SDK v75 08-2023
SDK v76 10-2023

What do we need to do so both clients can work with us ?

  1. Use SDK v76 in our integration and ask client A to recreate credentials ?
  2. Use SDK v76 in our integration, client A is ok as it is.
  3. Have two integrations on our side, one for each SDK, and use v75 for client A et v76 for client B
  4. Change our integration to go through Stripe connect with direct payments (wondering if it also support two step payments : auth and capture).
thorny crown
#

you shouldn't be collecting the API keys

#

what we suggested both my colleague and myself is instead to Connect as a Platform to the accounts in question and use Direct Charges to create the Payments on their behalf

#

Change our integration to go through Stripe connect with direct payments (wondering if it also support two step payments : auth and capture).
yes it does

echo sequoia
#

Ok, will talk with the team about working that way. As today we are asking clients to set they API secret in our system, and that is not recommended.

thorny crown
#

correct

echo sequoia
#

Thanks for your help, much appreciated