#SB WT
1 messages · Page 1 of 1 (latest)
hi! I suppose it should be, what are 'payment logics' exactly?
MARKETPLACE CURRENT PAYMENT LOGIC: At the moment our payment logic is a) customer accepts proposal price b) their card is pre-authorised holding the full amount with Stripe as our payment gateway. For cancellations up to 12 weeks before the event start date: full refund to the customer (full payment minus Stripe admin fees released). For cancellations up to 4 weeks before the event start date: no refund to the customer. All being well, the event goes ahead and Stripe releases the funds to supplier on the last day of the event minus fees, tax and commission. This takes up to 2 weeks to process.
MARKETPLACE NEW PAYMENT LOGICS (TOGGLE): in order to fulfil more suppliers onboarding with us, I want to explore the potential for us to create multiple payment logics which we can toggle per supplier need. We can review these as the business matures. What are the risks and benefits of each?
- 50% deposit paid up front (minus fees, tax and commission), 50% day of event
- 50% deposit paid up front (minus fees, tax and commission), 50% last day of event
- Existing logic
to be clear, you are now asking me to give you the risks/benefits of those options?
in any case, all this logic is outside of Stripe(the amount to charge, when, the timing of when and if to issue refunds, is all business logic, and you can call our API to do any or all of those things) so not really a technical question I can have much insight into
there's no concept of a 'mode' or 'logic' inside Stripe, the API just does what you tell it do, you can certainly have in your own app the concept of modes of operation that you switch between though, different code branches that makes different API calls.
Hi! I'm taking over my colleague. Please, let me know if you have any other questions.