#Step-invoice-branding
urban steppe
Hi there 👋 could you provide the ID of a subscription where you saw this behavior that I can take a closer look at?
sly orbit
Not really, we're only testing
We have a custom checkout page created by our developer. The developer must charge the users twice. One for the one-time payments and use subscription payment for second payment for the recurring,
We cannot charge everything within 1 invoice.
The one-time invoices are branded for our partners, but the subscription invoices are branded with ours. No possibility to change those to our partners
Is there a workaround for this?
Instead of charging our customers twice, can we charge them once? But have the recurring payments also be charged automatically? While keeping our partner's branding intact
sly orbit
for 1 product, we gotta charge twice, that's the problem
Product 1: one-time payment & recurring payments
But our dev must create 2 payments to get this going.
glossy moon
@sly orbit but why do you have 2 payments? You can do all of this in one payment. Also we need real example ids of objects to help you debug this
sly orbit
Because our partners receive a % split, right?
glossy moon
You can still handle all of it in one payment
sly orbit
The developer said it in the stripe flows, it does not allow to create 1 payment. One payment for one-time payment and one payment for subscription payment. Other wise, we cannot pay split % to our partners
glossy moon
that's not really true
You can decide to have a $100 monthly price, with 10% for yourself ($10) and an extra $23 one-off item for the first invoice. Total is $123 and you can control how much to send to the connected account ($90and keep $33 for yourself) for example
There are many ways to do this, it depends on many different factors
sly orbit
yes, but what about paying recurring % to our partners?
because there is a $100 monthly price, the partner must get paid % every month
glossy moon
Ah yeah I see, that's because transfer_data expects a percentage but that's still possible in 2 ways
1/ Create a one-time payment for the sum of all, so in my example $123, and set transfer_data[amount] to $90 (their share). Separately create a subscription that starts in a month for $100 and the 90% for them
2/ Create a Subscription for the $100 recurring price and the one-time item in add_invoice_items and do the math so that you keep $33 for yourself. So instead of keeping 10%, you want to keep 26.9%. This means you get the $33 upfront. Then you can update the Subscription to have transfer_data[amount_percent] set to 10% (the correct percentage on future invoices)
Both options have downsides and require more code unfortunately but they work
sly orbit
The main main thing is for the partner branding to be respected
Because in terms of functionality, we already have a turnaround, which was the 2 payments. One for the one-time payments and one for the subscriptions.
But then we realized the subscription invoices are not pulling the partner brand. It is not even possible.
So now, with the first and second option that you provided, can our partner's brand be respected in all ways? From the stripe connect custom checkout page, to the invoices that are thereafter created?
glossy moon
It is not even possible.
that's also not really true
I'm sorry, let's pause: please provide clear example object ids for the payment and the subscription and explain which exact branding you see
sly orbit
What we had in the begining, before splitting the payment into 2 payments, we have 1 payment. But we realized that the partner would only get the split % payment on first payment, not recurring.
That's just to give you insight on a bit of our testing and developing process
Then we tried the 2 payment version, with subscription, which then my dev said we cannot have our partners brand on that.
Then here we are, in this chat
just for context ^
glossy moon
yeah but some of it is your own assumptions and not really true
but it would be way easier to approach it differently. Please provide clear examples. Concrete real ones, so that we talk about the exact same thing
sly orbit
It's what I've heard from dev. I manage the project. I'm not dev. You have KB or articles on how to have 1 payment for a product that uses both one-time and recurring, which allows our partners to get paid on all recurring payments AND generates partner branded invoice for each recurring payment
glossy moon
I'm sorry, I know that seems like an easy question but it's not, it depends on many different factors (flavour of Connect, where the sub is created, where the payment is created). We could spend 3 hours talking and make no progress without clear examples that ensure we say the same things,
I would strongly recommend that you send the dev here instead and have them provide detailed actionable information with exact existing object ids so that we can look at them
sly orbit
Okay let me write it out for you:
We are a marketing agency, providing specific services to real estate agents. We want to onboard real estate firms, so they can sell our services to their agents. We want these firms to become the providers of marketing services to their real estate agents. So we had to come up with a fully whitelabeled solution. For the payments, as well as servicing their agents.
For the payment part, we decided to work with Stripe Connect, that way we can onboard these firms to become our partners. Then we created custom checkout/shop pages (something like this: http://phpstack-260718-2349907.cloudwaysapps.com/) to provide to our partners. Then partners would their shop link to their agents.
Agents would then buy OUR services, through partner shop (the link above), then our partners get paid commission.
Some of our products are recurring only. Some are one-time payments. Some are One-time (setup cost) and recurring payment.
At first, we had all within 1 payment, but our dev said that we can only have them paid on the first invoice. Not the recurring one.
Then we splited the payments for 1 product (one-time and recurring) to have our partners paid on all recurring payments as well.
Dev came back saying that the invoices are branded, but the subscription invoices aren't.
We need to either fix what we have right now (brand the subscription invoice to our partner), or come up with a different approach, simpler approach that fixes this entirely.
The main thing that needs to be respected is the whitelabel part. Where the invoices and everything the real estate agents puchases, must show the firm's (our partner) branding.
glossy moon
I'm sorry
I really need just real object ids
I can't do anything without it, you stay high level with the business model, which is helpful but not what I need.
sly orbit
Sure, product ID?
glossy moon
no
I need to talk to the person who understands the exact code/integration and which object(s) they create. I need to see the Charge that has proper branding and the one that doesn't, the ch_123 which clear details on how each is created and what branding is/isn't seen so that I can compare and explain what to fix
sly orbit
Can we keep this thread alive until tomorrow? The dev is in a different timezone, he is offline.
Or can I add you as dev in our stripe account?
glossy moon
No, there are way too many threads in a day. It's totally fine to ask as a new question, mostly the dev need to show the two charges and say "first one has branding, second doesn't, how can I fix it" and we can explain!
sly orbit
Is there a way to save this conversation then? Transcript or something?
glossy moon
the thread will stay visible forever, but really that conversation won't really help for the next discussion so you don't need it. But you can search for it easily in Discord by looking for threads/messages made by you
like this
sly orbit
Alright thank you. I will try to have our dev come in with me next time
glossy moon
Awesome!
sly orbit
Thanks a lot for the help.
But wait before we close this
any links or articles or documentation that can help dev before we contat you guys?
glossy moon
sure thing, I do see what you describe and really once we have the charge ids we'll tell you "oh that's because of X, you need to do Y instead"
no articles no
sly orbit
Sounds good, thank you