#hendie_api

1 messages · Page 1 of 1 (latest)

snow knollBOT
vague sierraBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

snow knollBOT
#

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

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

thorny vault
#

hi there!

#

how are you accepting payments? Checkout Session, Payment Element, something else?

hasty garnet
#

we use our own checkout flow, but we do use the above Stripe features to tokenize or charge.

#

one more issue we are seeing is that for terminal transaction in AU, you seem to have a limitation that we cannot use setup_future_usage and card_present payment method type. We can specify this in the US for example, but not AU, and I cannot find any documentation that explains why.

wooden ledge
#

Hi there 👋 apologies for the delay. I'm jumping in to lend a hand, please bear with me a moment while I catch up on the context here.

hasty garnet
#

So we have three issues we need help with for our AU integration:

  1. calculating application fee based on card and network.
  2. calculating application fee for terminal transactions, and
  3. using setup_future_usage with card_present payment method type.
wooden ledge
#

First of all I want to mention that 90% of eftpos card are co branded with visa or mastercard

hasty garnet
#

I know

wooden ledge
#

So you can't decide before charing what network is used

hasty garnet
#

that's not the issue

#

I realize that, but we need the network in order to calculate our applications fee if we want to give the merchant the benefit of lower eftpos rates

wooden ledge
hasty garnet
#

how can we do that for non-user-facing transactions, like recurring montly charges

wooden ledge
#

You can use confirmation token with Subscription

hasty garnet
#

thanks, I will investigate the confirmation token option

wooden ledge
#

Like you collect the payment method and then make the charge/create a subscription

hasty garnet
#

we're not using subscription, we use regular payment intent processing for our recurring payments

wooden ledge
#

The idea is to collect as much details as possible on the payment method before making a purchase

hasty garnet
#

so you're saying we can use confirmation tokens for offline transactions too?

#

payment intents

wooden ledge
#

No you can use confirmation token with Stripe Subscription

hasty garnet
#

because the example you gave requires javascript, and that does not apply to offline transactions

wooden ledge
#

but if you are using Paymentintent, then you can use SetupIntents

#

first to collect the payment method details and then compute the fees

hasty garnet
#

what if it's a token-based transaction with a token we captured in the past

#

does the setup intent give us "payment method details" including network?

#

and can a setup intent be used with an existing pm token?

wooden ledge
#

However, keep in mind that for co-branded cards you can't know in advance what network will be used before making a charge.

wooden ledge
hasty garnet
#

I know that, and that's our problem - how can we calculate an application fee for eftpos?

wooden ledge
hasty garnet
#

we don't need networks "available" we need network "used"

wooden ledge
#

The used is determined only at charge time for co-branded network, because there is multiple choices.

hasty garnet
#

I am familiar with the payment method object, and also that it doesn't have the network used for any particular transactions

wooden ledge
hasty garnet
wooden ledge
#

I'm affraid that you can't compute it before making the charge

hasty garnet
#

thing is regular credit card fees are substantially more than eftpos fees

#

can we ask that this issue be investigated by Stripe - it severely limits us from giving our AU merchants a fair fee.

#

since the application fee does not affect the amount of the transaction, only how the funds is distributed to the merchant and the platform, there should be a way of changing the application fee even after the charge ius made with the network.

wooden ledge
#

there should be a way of changing the application fee even after the charge ius made with the network.
Stripe fees are subtracted from the Account owning the charge. For direct charges, the connect account is responible for paying the Stripe Fees and for Destination Charges, the Platform Account is responsible for paying the Stripe Fees.

hasty garnet
#

and as you admitted that last link you sent me is not 100% guaranteed to pass the stripe fee on to the merchant correctly. You are intergrating with moreand more networks and payment systems - one would hope that you keep that in mind for such feartures

wooden ledge
#

100% guaranteed to pass the stripe fee on to the merchant correctly.
Why you are passing manually the Stripe Fees to the merchant? if you want the Connect Account to pay the Stripe Fees than you can use Standard Accounts with Direct charges

#

Then you don't need to compute adjust nothing.

hasty garnet
hasty garnet
#

we also have to use Custom accounts

wooden ledge
#

Ah I see, in that case yes I'm affraid that there is no workaround...

hasty garnet
#

which is why I asked that it be filed as a "feature" request.

#

essentially a way to update the application fee after charge, but before payouts

#

that should not be too difficult?

#

you'd have to agree that updating the application fee after the charge is the only way in which we (the platform) can have all the information about the charge, the pm and the network that we need,.

#

so I have two more questions, can we go to the second now?

#

it's the first comment I made after the initial request for assistance

wooden ledge
wooden ledge
hasty garnet
#

I will file this with support, thanks

#

in the second scenario we should be able to kinda do what we want, by using the beta feature "Optionally inspect payment method details", and then sending a new application fee in the capture ... theoretically

#

this works for regular credit cards, but not for interac canada for example. In that case we have found that the transaction is actually already complete at that time, and the capture in point 4 on that page is not used, and again we cannot update the application fee. So we are concerned that the same will happen for eftpos.

#

can you confirm?

vague sierraBOT
hasty garnet
#

back when we discovered this I put in a request for a solution to the problem for interac, but cannot find any evidence that it has been fixed.

wooden ledge
#

this works for regular credit cards, but not for interac canada for example. In that case we have found that the transaction is actually already complete at that time,
You mean that payment intent is confirmed without calling terminal.processPayment ?

#

Can you share an example of a PaymentIntent ?

hasty garnet
#

this is for terminal transactions if I forgot to mention

#

no, processPayment yields a PI with status 'success' and not 'requires_capture'

#

unfortunately I don't have an example, no

#

but I can assure you that's howe it works with interac

wooden ledge
hasty garnet
#

I guess an interac charge is immediately confirmed

wooden ledge
#

Sorry, but we need an example of a PI to narrow this better with you

hasty garnet
#

we always use manual capture with terminal transactions

umbral ocean
#

👋 yes interac payments are captured automatically

hasty garnet
#

we don't know at point 1 Create a Payment Intent, whether it will be interac or anything else, so we always follow manual capturee

#

so my question is, co eftpos transactions also get captured automatically>?

umbral ocean
hasty garnet
#

thanks, that answers my question

#

now, question 3

#

From above : one more issue we are seeing is that for terminal transaction in AU, you seem to have a limitation that we cannot use setup_future_usage and card_present payment method type. We can specify this in the US for example, but not AU, and I cannot find any documentation that explains why.

umbral ocean
hasty garnet
#

ah, ok, thanks

#

I think that's it for today 🙂

#

thank you for your help

#

how do I save a transcript of this chat?