#whitebunny80_api

1 messages · Page 1 of 1 (latest)

dull escarpBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1369907474773053511

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

wise forge
#

I checked the github ticket and the content seems like AI-generated to me.

pure shard
#

Hi jack. Thanks for reaching out. We explored creating connection tokens using the stripe account of the connected business. This works fine, but it implies the payment will be routed to the connected account for which the token is created?

What we are trying to achieve is to dynamic payments like

[multiple dynamic connect accounts] -> [multiple connect accounts]

wise forge
#

I don't quite understand what you mean by "[multiple dynamic connect accounts] -> [multiple connect accounts]" , can you elaborate?

pure shard
#

Sure. We are onboarding businesses and charities in our platform as stripe connect accounts.
businesses will log in in our app and accept payments dynamically to:

  1. Themselves (tips). In this scenario what you suggest works fine (create the terminal token in the context of the connected business)
  2. Charities (in the form of other connect accounts to our platform). THe user will be prompted to donate to the supported charities, where charities are other connect accounts onboarded in our platform
#

In the latter we need to support direct charges towards those charities

#

The way Terminal creates API objects depends on whether you use direct charges or destination charges. If you use direct charges, all payment-related Terminal API objects belong to connected accounts while readers might belong to either the connected account or the platform

This sentence leads me to believe we can create the terminal in the context of the platform (us), and create payment intents (client or server side) dynamically to other connect accounts

wise forge
#

" create the terminal in the context of the platform (us)," -> what's the terminal in this sentence? Are you referring it to the terminal reader?

pure shard
#

For extra context we managed to prototype this fully using destination charges.

We create a single tap to pay terminal instance in the context of the platform and we route the intent dynamically to the target account client side.

Given fee structure and extra charities requirements we need to shift to direct charges.
I am not sure it would be feasible to dynamically recreate tap to pay terminals in a timely matter?

wise forge
#

I assume the "terminal" is the terminal reader. And the answer is no, you can't use reader created on platform to collect direct charges on connected accounts

pure shard
wise forge
#

Yes you are right

pure shard
#

Ok, some ideas, let me know if they could be feasible:

  1. Can we instantiante multiple terminal readers (connected to different accounts) connected at the same time on the same physical "Tap to Pay" hardware.
  2. Can we disconnect / reconnect a terminal reader on a different stripe account dynamically? Of course we would need to validate if the time taken is acceptable for our use case
#

These are ideas that popped up in case dynamic routing was not possible

wise forge
#

No, you can't associate one terminal reader with multiple accounts simultaneously

pure shard
#

This voids 1

#

Option 2 still on the table if we disconnect and reconnect on a different account right

wise forge
#

Yes you can do that. When you pair the reader to another account, it'll automatically be disconnected to the previoulsy connected account.

pure shard
#

I have another question. We wanted to explore copping the fees for a period for direct charges. Your onboarding experience mentions to contact sales. Sales redirected us to support, and support is now telling us to use separates charges. I don't think this is correct

wise forge
#

Can you tell me which part is incorrect?

pure shard
#

So we want to absorb stripe fees for direct charges (configuration shown above). Support suggested us to use Separates charges and transfers, but that seems a complete different configuration

#

You cant select Stripe full dashboard. Liability also falls on Platform.

#

In other words we want to enable this:

But we get an error if we do so

image.png
wise forge
#

I still don't quite get your concern. If you choose "Separate charges and transfers", you can only choose "Your platform" for who pays stripe fees.

#

Isn't that what you want to achieve?

pure shard
#

We can't take negative balance liability with charities

#

the payment must be a direct charge, as well as they should be able to provide receipts directly

wise forge
#

"So we want to absorb stripe fees for direct charges" -> my understanding is that you want to be responseible for the stripe fee, no?

pure shard
#

Yes. Current our configuration is
Onboarding: Hosted
Dashboard: Full
Charge: Direct
Fees: Connected Account
Negative balance: Stripe

This setup allows to also select Fees: Your connected account

wise forge
#

Let's take a step back, do you want the platform, or the connected account to be esponseible for the stripe fee?

pure shard
#

Pardon me, I think I am confusing you. This is our current setup:

Onboarding: Hosted
Dashboard: Full
Charge: Direct
Fees: Connected Account
Negative balance: Stripe

At the moment, the connected account is responsible for the fees. All good.

We want to trial absorbing stripe fees for a period of time. We can't change the flow though (direct charges) because:

  1. We still want the connected account to deal directly with refunds and disputes
  2. We can't assume negative balance liability

The onboarding form allows changing fees from connected accounts to platform. That creates a controller of
fees.payer.application

When we try to do that we receive an error

wise forge
#

Ok, got it. You won't be able to update the account's controller, so the workaround here is to create a new connected account with the right controller setup for destination charge or separate charges and transfers so that the platform can be responsible for the processing fee.

pure shard
#

Alrite. Thanks for letting me know we won't be able to change the controller on an existing account. That would have been my next question 😄
At this stage tho we are also unable to set the controller.fees.payer = application when using direct charges

#

That seems to be a valid options

# 
INFO:stripe:error_code=None error_message='`fees[payer]=application` is not supported when creating an account with the full dashboard.' error_param=None error_type=invalid_request_error message='Stripe v1 API error received'
wise forge
pure shard
#

It is our understanding it needs to be enabled

#

req_XTPs1G5VH0KjiO

# 
Stripe API error: Request req_XTPs1G5VH0KjiO: `fees[payer]=application` is not supported when creating an account with the full dashboard.
wise forge
pure shard
#

Weird. If you jump on your onboarding page: https://docs.stripe.com/connect/design-an-integration it does allow you to create this combo.
If you then click on "Use the onboarding quick start" it does provide this configuration that produces the error.

The only thing that pops up is to contact sale to discuss

image.png
wise forge
#

Yes, looks like the information presented in the integraiton guide isn't 100% accurate. I'll feed back to the docs team.