#denjaland_api

1 messages · Page 1 of 1 (latest)

gaunt egretBOT
crimson groveBOT
#

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.

gaunt egretBOT
#

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

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

granite burrow
#

Hi, any specific part that's unclear?

glossy parrot
#

Hiya - I'm a bit confused to how incoming bank transfers work. Is there a way that I can basically have 1 SEPA accout to accept all customer payments from, and that I have them includ. payment reference that is just passed to use on our side?

#

or is it so that each "customer" requires a seperate bank account?

#

I'm a bit confused to be honest 🙂

granite burrow
#

Each customer will have their own virtual bank account.

glossy parrot
#

I was hoping we could have just one destination IBAN, and have the customer include a reference on the payment that was communicated to use to be able to link it in our accounting

#

okay

#

so in order to accept a payment, I create a new paymentintent which creates a nex virtual bank account

#

but it's basically a general bank balance? I can not have the customer pay with a reference?

granite burrow
glossy parrot
#

let's say I have 2 open invoices on a customer's account

#

he wants to pay invoice 1, but rejects invoice 2

#

when the payment is being received, I don't have a way to match it to invoice 1, I believe

#

because the payment intent details does not come with a reference he needs to include on the payment right?

#

so basically I can not have a customer pay for a specific purpose, but he's actually managing a virtyal bank account that we debit from directly, right?

granite burrow
#

Each PaymentIntent will have a reference that they can attach to the transfer.

glossy parrot
#

how do they do that? by adding a remittance reference in the transfer?

granite burrow
#

Correct.

glossy parrot
#

I completely missed this bit to be honest

image.png
granite burrow
#

Yes, it's rather different from other payment method types, and not used that often too.

glossy parrot
#

so when a payment is received from the customer including that reference, that particular paymentintent will be marked as received by you and we get the webhook call, right?

#

what if the payment does not match such reference - the payment will just go into the customer's balance, but I don't get an updated paymentintent call, right? How would I handle that case then?

granite burrow
granite burrow
glossy parrot
#

okay

#

so let's say we manage the balance of the account in our proprietary software

#

whenever we detect an overpayment

granite burrow
#

For underpayment you should listen to payment_intent.partially_funded actually. I believe if they forget to add the reference, the amount will be added to their cash balance, and Stripe will attempt to use it to pay the first outstanding PaymentIntent/Invoice.

glossy parrot
#

the best way to handle this, is to then create a paymentintent so it's funded by the overpayment, and then we can handle that as any other payment, right?

#

yes - I understand the underpayment, but sometimes we have customers spontaneously overpaying which we keep on their customer balance in our own account

#

so the best way for me seems that if we detect overpayment at stripe

#

we create a paymentintent so we can have the balance "flow" from the stripe customer account to a "payments received" in our software

#

because if we leave it at stripe, it'll be applied to future payment intents, and that would send the payment to us as being received, so that wouldn't add up

#

does that make sense?

underpayment -> we just get payment_intent updates
overpayment -> whenever we detect a customer_balance, we just create a payment_intent to "transfer" it from the stripe customer balance, and treat the payment on our end as an internal overpayment

#

so basically on cash_balance.fund_available, we could just respond by creating a payment_intent which will automatically be funded

granite burrow
#

So, basically you want to move the remaining funds from overpayment from customer balance to your balance?

glossy parrot
#

what do you mean 'your balance'? isn't a payment when received aumatically paied out, even if it's an overpayment?

#

so a customer balance remains with stripe unless used for a paymentintent?

granite burrow
granite burrow
glossy parrot
#

yes, but you mean that for an overpayment, unless I transfer it using a payment intent, it will not be paid out and stripe considers it as being balance of the customer, right?

#

okay

#

so I'm guessing my flow is correct

#

detect customer balances, create a payment intent to transfer to my balance (and internally track the overpayment)

#

so if I "refund" that payment intent, the payment will flow back to the customer balance, but not automatically be refunded to the customer then? I'd need to manualle process that, right?

granite burrow