#njord_api

1 messages · Page 1 of 1 (latest)

brisk walrusBOT
#

👋 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/1386724254401298444

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

hidden totem
#

Hi 👋 can you tell me more about why dynamic statement descriptors didn't suit your needs, or share more context on what you want your statement descriptors to look like?

Offhand, dynamic descriptors would sound like the best fit, since you could adjust the suffix to be consistent, though you may need to handle payments on the Platform account so a consistent prefix is used.

oblique oriole
#

Certainly! Thanks for your help.

With a dynamic descriptor, it only affects the value after the *, correct? With both in the statement descriptor the character limits become a problem as well.

For more background, we're currently using destination charges and card payments.

#

By only modifying the suffix, customers will still see connected account B's business on the statement, causing confusion. If I can change that, it wouldn't be a problem.

hidden totem
#

So you're using on_behalf_of in your destination charge flow (since it sounds like you're seeing the Connected Account's prefix rather than your Platform's)?

#

The short answer to your initial question is no, it's not possible to process a payment where one Connected Account is the settlement merchant (on_behalf_of) and use the statement descriptor of a different Connected Account. Because that would be confusing to customers.

So I'm trying to get a better feel for your constraints to see what workarounds there are.

oblique oriole
#

Typically, the on_behalf_of matches the destination connected account. We are invisible to the customers, we promote the connected accounts business so we don't want our name (the platform) on the statement either.

This works well in most situations, until we have 2 connected accounts (A & B) that are both doing business on behalf of A.

#

Then it gets a little complicated 😅

#

The error message on the request is the following (test environment). Both accounts are in the same country in this test:

You cannot specify an on_behalf_of value that is different from the transfer_data[destination] value when using card or card_present in payment_method_types. This is because when you are using destination charging, Stripe must settle charges in the country of the destination account. You can learn more about charges and transfers here: https://stripe.com/docs/connect/separate-charges-and-transfers#on-behalf-of

hidden totem
#

Yup, that's expected, you can't process a payment on behalf of a connected account that they're doing on behalf of another connected account.

oblique oriole
#

That makes complete sense

hidden totem
#

And if your Platform needs to remain invisible, I don't really think there's a way around this

oblique oriole
#

I really just want to change the statement on the credit card

#

So is the non-suffix/descriptor statement descriptor essentially tied to the on_behalf_of parameter?

hidden totem
oblique oriole
#

Very helpful thank you!

While I have you, I have a related question:

We'll be splitting payments amongst numerous connected accounts soon. For example, customer makes a $100 payment,

Connected account A receives $70
Connected account B receives $30

Do you know how that appears on the customers credit card statement? Is it two charges (70,30) or is it 1 charge (100)

hidden totem
#

Are you implementing it as two distinct Destination Charges, or are you going to use Separate Charges & Transfer to process one payment on the platform and then transfer funds to your Connected Accounts?

oblique oriole
#

Going to use separate charges and transfers.

hidden totem
#

Then it'll look like a single charge

oblique oriole
#

That's super cool!

#

So if connected account A & B are both being sent money, who's on the statement descriptor?

hidden totem
#

It's the Platform by default for Separate Charges & Transfers, but that flow also supports on_behalf_of and let's you specify a Connected Account as the settlement merchant
...
and as I typed that I'm realizing that's probably the best fit here 😅 (as long as we don't block you from making a Transfer to another Connected Account as well, which I'm pretty sure we don't)

oblique oriole
#

This is a very convoluted scenario I've thrown at you, and you've been very helpful. I very much appreciate it.

I was thinking about trying this, but I think in the scenario I mentioned the connected account B gets all of the money sometimes, in which case I'm guessing I can't put account A on since they aren't one of the destinations?

#

This does solve the issue for me when I split a single payment amongst multiple platform accounts including the dba account.

hidden totem
#

I'm working on spinning up a test to see if I can quickly confirm whether on_behalf_of will give you any grief in this situation

oblique oriole
#

Wow, stellar customer support you are the man

hidden totem
#

I didn't run into any errors along the way, but let me know if you do.

What I did:

  • Process a Payment Intent with on_behalf_of set to Connected Account A
  • Created a Transfer to Connected Account B, but used source_transaction to tie the Transfer availability to the Charge from the payment.
Create separate charges and transfers

Create charges on your platform account and transfer funds to multiple connected accounts.

oblique oriole
#

I'm reading and trying to catch up here...

#

This seems like a great solution. I'm going to try this on my end.

This might take me awhile to test out on my end.

brisk walrusBOT
hidden totem
#

Sounds good! Feel free to reach out if you run into any trouble along the way. If this thread has been closed by then, feel free to open another one via the #help channel and we'll be happy to help.