#salonmonster_best-practices

1 messages · Page 1 of 1 (latest)

lost carbonBOT
#

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

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

lime tangle
#

We run a Connect platform using Stripe Terminal in salons (Canada + USD where relevant). We charge an application fee per transaction to cover network + Stripe costs:
• Card-present credit: 2.65%
• Online / card on file: 2.9% + $0.30
• Interac debit (in-person): $0.12

Our current workflow / config
• Connect: Destination Charges pattern — on_behalf_of + transfer_data.destination to the salon’s connected account.
• Terminal: We include card_present (and in CAD also interac_present) in payment_method_types.
• Why we previously used manual capture: We don’t know the card type until the tap. Historically we used capture_method: "manual" so we could:
1. send the PaymentIntent to the reader,
2. see what the client tapped (credit vs Interac),
3. set the correct application_fee_amount, then
4. capture.
• What changed: Interac now requires automatic capture (no manual capture with interac_present). So the fee must be decided before the reader confirms.

#

Options we’re considering

Option A — Keep Destination Charges and do a post-tap fee correction (our front-runner):
Create the PaymentIntent with automatic capture and a provisional “max” fee (e.g., 2.65%). After payment_intent.succeeded, read payment_method_details.type. If it was Interac, issue an Application Fee Refund for the difference (bringing our fee to $0.12).
Pros: Minimal changes; same funds flow and liability model we use today.
Cons: Occasional fee refunds; we’ll implement idempotent webhook logic.

Option B — Separate Charges & Transfers (SCT):
Charge on the platform account (no application fee up front), then, once we know the method, create a Transfer to the connected account for (gross − our fee), linking via transfer_group/source_transaction.
Pros: No fee refunds; exact fee once.
Cons: Operationally different: platform balance management; and (as we understand it) disputes/negative balances still hit the platform.

Option C — Direct Charges on the connected account:
Charge on the connected account and collect our fee via application_fee_amount. To handle Interac vs credit, we’d likely follow the same “provisional then Application Fee Refund” approach post-payment.
Pros: (As we understand) shifts dispute liability toward the connected account.
Cons: Product/ops changes for our merchants; still involves fee refunds if the card type isn’t known pre-confirmation.

Option D – Whatever Stripe recommends

#

Questions for your recommendation
1. Given the Interac auto-capture requirement, is Option A (Destination Charges + Application Fee Refund correction) the approach Stripe recommends as best practice for Terminal platforms that can’t know the card type before the tap?
2. Is there any Terminal/Connect flow that exposes the final payment method type early enough (pre-confirmation) for us to set the exact application_fee_amount without refunds?
3. For Option A, can you confirm this is fully compliant and typical:
• Create PI with auto-capture and provisional fee
• On payment_intent.succeeded, check payment_method_details.type
• If Interac, call Application Fee Refunds for the difference (this returns funds to the connected account and does not affect the customer’s charge)
4. If Stripe has a canonical sample or doc page that shows this exact scenario (Terminal + Connect + Interac auto-capture + post-tap fee handling), we’d love a pointer.

Our goal is to keep the experience smooth on the reader (no “debit vs credit?” prompts), keep our merchants’ accounting clean, and follow Stripe’s preferred pattern.

Thanks so much for your guidance!

lost carbonBOT
lime tangle
#

(sorry I know that's a lot to read)

upbeat rain
#

Hi there,
looking into this but please give me some time to read through this. I will also need to taalk to another colleague since it's a multi layered question. So don't be surprised if you don't hear from me immediately.

lime tangle
#

No prob - thanks for thinking it over

#

Let me know any info you need, or clarification

upbeat rain
#

One question, when you say "Interac now requires automatic capture", what do you mean? Has it ever worked with manual capture for you? Beause Interac never supported manual capture before. So I just want to make sure we are on the same page

lime tangle
#

18.4.0 sdk did actually allow manual capture on Interac.

The release of 18.5.0 no longer allows it

#

That's how we have been running our flow for the last couple of years

#

But with 18.5.0 it now returns an error.

lapis rivet
#

Hello
Jumping in to help out here

lime tangle
#

From what I can find it was a March 31, 2025 update to align with Interac network’s single-message behavior, which requires automatic capture

#

Hi Hanzo

lapis rivet
#

We don't have a recommended path for this flow as authorization and capture has to happen in just a single step

#

The flows you've outlined above

#

all seem fine

lime tangle
#

It must be a very common question as you don't want to have to ask the client "is it debit or credit" before passing them the terminal

#

Is there any of the flows that seem better from your experience?

lapis rivet
#

This behavior is specific to Interac though, not all debit/credit cards.

Platforms usually pick the flow that fits better with their integration.

lime tangle
#

I'm leaning towards charging the higher rate and then refunding - so long as I don't incur a cost for that

#

(Partly because it involves the least re-coding)

lapis rivet
#

Since you're using Destination Charges + OBO, your Connected Account is the Merchant of Record.
You could do Separate Charges and Transfers with OBO

#

So you don't need to refund anything

lime tangle
#

Ok

#

So that would be:

Charge on the platform account (no application fee up front), then, once we know the method, create a Transfer to the connected account for (gross − our fee), linking via transfer_group/source_transaction.

lapis rivet
#

My team won't know much about fees so I don't know if Application Fee refund costs extra or not but assuming it does, the above flow would be the workaround

#

Charge on the platform account (no application fee up front), then, once we know the method, create a Transfer to the connected account for (gross − our fee), linking via transfer_group/source_transaction.
Correct

lime tangle
#

Thanks

#

Is it typical for SAAS platforms like us to be operating as Merchant of record? Or is it better to make charges on the connected account?

#

I expect it's just case by case 😛

lapis rivet
#

It differs from Platform to Platform 🙂
Yup

lime tangle
#

Okay, thanks for the guidance. I'll proceed with that method

lapis rivet
#

NP! 🙂 happy to help