#brianc-destination-charges

1 messages · Page 1 of 1 (latest)

left tundra
livid pier
#

Hey there 👋

#

Yup, as long as you'd like the transactions to be recorded against the sub-merchant's account, along with them receiving the transfer, then they'll be the same.

bronze gale
#

Since it is a connected Express account and we are creating a destination charge (on_behalf_of), isn't it implicit that the transaction is recorded against the sub-merchant account? I'm not sure what other options there would be? What else would we set the transfer_data[destination] to? and why? I don;t fully understand the point.

livid pier
#

Give me a moment to try and clarify.

#

Apologies. If you are using the on_behalf_of parameter then that will always need to match the value you pass in for transfer_data[destination].

I was thinking of a scenario where transfer_data[destination] is specified, but on_behalf_of is not, but I don't think that applies to your scenario. Apologies again for that mixup.

bronze gale
#

Thank you but still not making complete sense. Why do we need to provide the transfer_data[destination] at all when we assign the on_behalf_of flagging a desination charge?

"The transfer_data[destination] is the ID of the connected account that receives the transfer."

Can you specify what is considered "the transfer"? Is it the transaction or the actual funds?

left tundra
#

It's transfer_data[destination] which indicates the destination charge, you've just started from the optional additional on_behalf_of

#

To create a destination charge you must use transfer_data[destination].

Optionally, you might want to use on_behalf_of to change the settlement/merchant of record

bronze gale
#

OK. Thank you for that. "The on_behalf_of parameter is the ID of the connected account to use as the business of record for the payment".

For a Connected Express account, is it even possible to change the busines of record? I thought the whole point of Express vs. Standard was the business of record assignment?

My apologies but this language is not terribly clear.

left tundra
#

with standard account you should use direct charges, which yes will have that account as the merchant of record

#

with express accounts you use destination charges. by default the platform will be the merchant of record, but you can optionally use OBO to set it as the connected account.

bronze gale
#

OK. Thank you. That is news to me! I'm assuming that the OBO simply controls what the customer sees on their statement, but clearly does not affect the liability for chargebacks, correct?

#

We have been using tokenized cards or charges on express accounts and I believe the default is to list the sub-merchant's info as merchant of record. Using RequestOptions on the charge. Is it true that this now needs to be set otherwise it defaults to the platform?

This is kind of crucial info for us so I appreciate your time and help with clarifying all of this.

left tundra
#

CAn you share an example payment you're doing?

bronze gale
#

Which one, old method or new?

#

Tokenized or intents

#

?

left tundra
#

Intents

bronze gale
#

Here is our PaymentIntent code:

var options = new PaymentIntentCreateOptions
{
Customer = customer.Id,
Amount = Convert.ToInt64(inputDetails.CartTotal * 100),
Currency = inputDetails.Currency,
PaymentMethodTypes = new List<string> { "card" },
ApplicationFeeAmount = Convert.ToInt64(Convert.ToDecimal(inputDetails.CartTotal) * gq.projectPercentageFee) * 100,
// OnBehalfOf = gq.ConnectedMerchantId,
TransferData = new PaymentIntentTransferDataOptions
{
Destination = gq.ConnectedMerchantId,
},

                };
left tundra
#

Well, whichever way you're currently using

#

I meant an example payment to look at but this is fine 🙂

bronze gale
#

Here is our setup intent (we have scenarios where we need both):
var options = new SetupIntentCreateOptions
{

                Usage = "off_session",
                Customer = customer.Id,
                OnBehalfOf = gq.ConnectedMerchantId,
                PaymentMethodTypes = new List<string>
              {
                "card",
              },
#

What we need to achieve is a destination charge to a connected account, the connected account's information should show up on the customer's credit card statement.

#

Charge code below - For paymentintents card is charged client side as we need to trigger SCA validation:

const { error: stripeError, paymentIntent } = await stripe.confirmCardPayment(
clientSecret,
{
payment_method: {
card: card,
billing_details: {
name: cardholderName,
},
},
}

left tundra
#

Yes, then if you want the merchant of record to shift that seems to be what you've got set here with on_behalf_of

bronze gale
#

To confirm, that is a change in default behavior from the previous "charge" method on Stripe. Correct?

#

The merchant of record defaulted to the sub-merchant and was not explicitly set to do so previously for destination charges to a connected Express account.

left tundra
#

When using transfer_data[destination], the settlement merchant can be specified with on_behalf_of. If you need to retain the behavior of destination[account], on_behalf_of must be explicitly set to the same value as transfer_data[destination].

bronze gale
#

Confirmed. Thanks. One more point of clarification:

" I'm assuming that the OBO simply controls what the customer sees on their statement, but clearly does not affect the liability for chargebacks, correct?" Which would be a true change in merchant of record in the literal sense (liability). In reality it only changes the statement descriptor, not the merchant of record.

left tundra
#

No, the OBO doesn't change the liability, your platform is still primarily responsible

bronze gale
#

Thanks or your help! Much appreciated!

left tundra
#

NP!