#Adrian Stefan-off_sesion

1 messages · Page 1 of 1 (latest)

orchid rampart
#

That sounds like expected behavior, Charges is a legacy API that will work with Sources (the card_ objects) but not PaymentMethods

#

What are you looking to do?

zealous mantle
#

we're trying to implement a saas with automatic charges (based on usage) and we're trying to make use of the existing payment method saved via the setupIntent

#

we haven't been able to figure out how to charge the payment method ...

orchid rampart
#

If you are using Charges, you will have to collect the details another way

zealous mantle
#

how do you suggest to make our case work ? We don't necessarily want to use charges, we want to use what's the best method. We also don't want to have to take PCI Compliance hence prefer the card not to go through our servers

orchid rampart
#

If you don't need to use Charges then I would recommend the current API, PaymentIntents

#

Unless there is a reason you know you cannot such as an unsupported payment type

#

Can you tell me a bit more about what you are trying to do here? Just as simple as set up a card and charge later?

zealous mantle
#

yes, charge multiple times later, say each time the customer reaches a set amount (50 EUR for example ) or at the end of each month

#

whichever comes first

orchid rampart
#

That way you can get the behavior through configuration instead of having to make it all yourself

zealous mantle
#

well, if I wanted to make it myself, would there even be a way ?

orchid rampart
#

Of course one moment

orchid rampart
#

I feel like I threw a bunch of info at you there. Do you have the info you need to go forward? Any further questions or clarification at the moment?

zealous mantle
#

sorry we were reading and pondering on the information presented

#

we tried using the payment intent off-session and seemingly it returns with a "requires_confirmation"

#

on the payment via metered billing we fear the nature of our service might hit some form of thresholds, although we don't know whether there's any ..., but in some situations the usage might spike on occasions

#

say a user makes a surge of requests within a short 1 second span or something of the sorts.

#

we were also having a gander at using invoices and adding line items to them then sending them with advance in order for their payment to be collected from the main payment method attached to the customer with the setupIntent

#

as I mentioned above, our preferred way would have been to get a paymentIntent created from the payment method saved via setupIntent as presented in the documentation you linked above, although, we haven't been able to make that work without receiving "requires_confirmation"

woeful sinew
#

I'm sorry I don't really follow what you've described unfortunately. We really recommend using Billing for all of this, it does everything for you automatically

#

@zealous mantle can you give maybe a concrete example of the flow of funds for a customer?

zealous mantle
#

we think we'll go with the subscription although the flow was as follows:

  1. A user signs up for our services.
  2. They receive a certain amount of free balance (similar to how google cloud console works)
  3. They start going through usage but have the option to stay with "Add balance" or "Pay early" and have a "planned" way to pay for their services BUT
  4. If the user depletes their funds and they have activated "pay as you go", their usage increases. Please note they can make usage on more than one product (type of request ) which have diferent price per request.
  5. Every so much balance accumulated, the said amount is debited from their set up payment method.
  6. Should the user have decided on using pay as you go at any point, they should not be able to remove the last payment method on file, as long as their account is active. (In order to make sure we have a way to charge for their usage)
#

basically this suits the metered billing to some extent , we don't, however, know how fast / often is the usage report api and how many items such a subscription can have.

#

also in case we launch new services, we'd like the user to be able to use them directly, and we don't know how exactly that would work through this api. each service has a diferent price and pricing usage model although all of them are metered

#

let's say that it's a product similar to a cloud provider

woeful sinew
#

know how fast / often is the usage report api and how many items such a subscription can have.
I don't really understand that question. What needs to be fast? What do you call items?

#

A subscription can have at most 20 separate prices, and it's quite high and rare to need that many. And you can report usage in real time all the time

zealous mantle
#

thanks, well, then we'll have an attempt at implementing this and come back here with our results

#

thanks a lot for your help