#holykent

1 messages · Page 1 of 1 (latest)

bleak fableBOT
manic wolf
#

hi! when you say invoice what specifically are the requirements for what you want to give to the host?

there are many possible options, as in we have an Invoices product (https://stripe.com/docs/invoicing) for one-time payments that generates an Invoice and accepts online payments for it, but our card-present product Terminal doesn't really integrate with it

noble grove
#

Well, precisely that then, I think.

The customer chooses Pay in Person, so a month from now when he's at the property he pays the host in person.

When the customer chooses this option, in our application we have to track what the host owes us. He should pay us our commission if the reservation was done through our site.

I was wondering mainly if this is something that can be done entirely weith stripe? i.e. list of invoices the hosts dashboard... or if this is more commonly solved through other channels or outside of the application

manic wolf
#

I think mostly that is the business logic that you're building as part of your platform. Your second sentence is definitely all state that would live in your system. When you say "invoice" you I think really mean like the details of what your customer is buying and thats's all something that lives with you
When the person is at the place and you decide that it's time to charge them, you'd interact with the Stripe API to process the card-present payment using Terminal, for example by reading your database to see what amount needs to be charged and passing that amount to our PaymentIntents API.

noble grove
#

but that doesn't help if the customer pays cash

#

we still need to ensure that the host pays us the owed amount, and i can't see another way to track that than outside of the system

#

so is a viable solution not to generate a list of invoices in the host dashbaord and allow them to pay like how a customer pays for a resrevation?

#

i guess most listings dont accept cash payment but still 😛

manic wolf
#

you would definitely be tracking some of this in your own system to be clear, you're going to have some database table with the details of your payments(and for payments that process through Stripe, you would have your server listen to webhooks for successful payments and update your database, for example)

noble grove
#

Yes, I see. so with card-present terminal, I would not need an invoice per se? provided we have the paymentmethodid and a customer object for the customer so that we can charge him when he uses the terminal?

manic wolf
#

well no, you don't use an existing PaymentMethod ID when using Terminal

noble grove
#

does stripe terminal really apply? these hosts could be anywhere

manic wolf
#

you create a new PaymentIntent(you can pass an existing Customer ID to associate it with that) and process it on the Terminal to collect+charge the card that the person presents to the reader

manic wolf
noble grove
#

Well, stripe terminal is not available in each country, and some customers may opt to pay hosts cash. If they do, yes, we've tracked how much the host owes us.. but how can we enforce that?

If the host pays us outside of the application, we'd have to handle everything manually (i.e. clearing/removing the invoie etc).

I was thinking we could do this entirely in teh application.

Host goes to dashboard, sees a list of invoices... uses stripe to pay the invoice. Now, that invoice is paid.

#

we have a grace period for invoices, if it's not met.. we just terminate their listing

#

so they'd have to pay us via the application, and via stripe. Since they already have a connect account to receive payouts, i dont see why they cant just do everything in the dashboard

manic wolf
#

the dashboard lets you do that as well

noble grove
#

and how would they pay it (via stripe, in application)? Just a paymentintent, like how a custoemr pays for a reservation+

manic wolf
#

ultimately I think you're trying to outsource a bit too much of this than makes sense, the whole concept of listings and pending payments is state of your systems/databases, Stripe just processes the actual payments

noble grove
#

or transfer? i dont want them to have to top up their stripe account

#

as they should have minimal interaction with stripe outside of the app

manic wolf
#

like a PaymentIntent needs to charge an actual payment method

#

presumably you're not going to have the host pay the PaymentIntent with their own card

noble grove
#

Ok let's back up. Im not trying to outsource the persistence of host invoice data to stripe, im trying to figure out if we can use stripe and stay in application for hosts to pay what they owe us.

if they start paying us outside the application, then I have to manually go in and mark the "invoice" as paid.

#

as soon as stuff occurs outsidfe fo teh application there's no reliable way for me to track what's paid and what isnt

#

it technically is an invoice ubt i dont mean the stripe invoice object. Just an invoice, i.e.... host owes us this much. we save that in the database. Can we make sure the host pays us the owed amount IN application (preferrably using stripe as that's what im using)

manic wolf
#

Can we make sure the host pays us the owed amount IN application
you can process a payment in Stripe against some payment method like a card or bank account you collected from the host, if you want.

noble grove
#

ok, so where does the stripe invoice object come into play? is it relevant in this situation? because I could just as well easily create an invoice entity in ym application and have a bool like IsPaid and an amount

#

isnt this effectively the same thing? what benefits do i get out of the invoice object?

manic wolf
#

it's up to you if you want to use the Invoice object or not

#

because I could just as well easily create an invoice entity in ym application and have a bool like IsPaid and an amount
that's what I think you should be doing

#

Stripe just process the payments, the whole concept of listings and pending payments is state of your systems/databases

noble grove
#

Gotcha, but si this a common practice for the situation im describing? i mean i can send an email as well, but if they dont pay WITHIN the application, then im not sure how i can tie an extenral, out of application bank payment to something in my database

manic wolf
#

then don't allow payments outside your application

noble grove
#

sure, i see. Ill look over it a bit, thanks for the help

manic wolf
#

then im not sure how i can tie an extenral, out of application bank payment to something in my database
not really understanding the question. You update your database bool (like the example you gave of an isPaid) to true, when you receive a notification 'somehow' that a payment has happened

noble grove
#

@manic wolfur right, it's not that complicated. the bank we're using to receive money when invoices are paid has some API support as well

#

so it should be trivial to get transaction info there and match it against teh reference numbers in my db

#

im assuming that's how it's commonly done

manic wolf
#

yes I mean if you're using multiple payments sources/processors here(Stripe, cash, a bank partner for transfers), you really need to build your own abstraction layer of "payments" on top of those into your system

#

we can probably help answer specific questions about how you hook that layer into specific parts of our API/products

noble grove
#

in application, only stripe. But if the user pays their invoice via direct bank transfer outsidfe of the application, obviously I cant use stripe to tell if htat payment's gone through

#

so i'd need to poll the bank for transaction data

#

and match reference numbers

#

so it's not really mixing with stripe at all

manic wolf
#

doesn't sound like it