Recurring payment via API based on dynamic pricing (Subscriptions API)

Hi guys,
I’d like to get an API solution for the following scenario:
Lets say we sell some merchandise by KGs / LBs.
So until now, we have a website in which the user enters the amount he wants in KGs, and then gets the Payment Form with the calculated price.

Now, we’d like to add a subscription functionality in which the price is still dynamic (by KGs) but it gets subtracted every month.
So if 150KG of fries is 150$, and a user selects a weekly subscription, we will get 150$ each and every week for a period of 6 months.
I need it all to be done with API.
Please note that the price is Dynamic so I can’t really create a specific product for it as the price changes by KGs.

I think relevant resources would be: Subscription API. But I couldn’t find the answer there.

Thanks a lot for your help guys,
Bar and the team :slight_smile:

Hi @LevelApp welcome to the forums!

There’s not a direct way to do this, unfortunately. If you wanted to use the Subscriptions API essentially you would:

  1. (Optional) save the card on file (Payment form, Dashboard, POS app)
  2. Each time a customer wants to start a new subscription, figure out the price
  3. Create a new subscription plan based on the price (and name it whatever)
  4. Set up a subscription for the customer on the above created subscription plan

Unfortunately, since each one would be dynamic, you’d essentially have to create a new subscription plan each time (which means, you’ll have a lot of subscription plans presumably).

Alternatively, if you wanted to build out your own subscription, you could:

  1. (Necessary, not optional) Save a card on file for a customer (Payment Form, Dashboard, or POS app)
  2. Every “cycle”, create an order (orders can all be ad-hoc, so it doesn’t matter if the price is dynamic…you can also create an item with variable pricing if you want to report on specific items better).
  3. Pay for the order (CreatePayment)
  4. Set up your own logic (like a cron job), to charge the customer’s card on file every cycle and repeat 2-3.

As I understand it saving a card and charging it via a cron/backend process is no longer possible given the new SCA verifyBuyer() requirements of EU/GB. So US merchants now lose the ability to charge cards via a batch process because there’s no REST API method for verifyBuyer() (or way to charge a card_id if SCA is not active for the location).

Please confirm and/or provide a different solution. My current workflow (using SqPaymentForm API and REST API) is:

  1. Present the card form and get a NONCE
  2. Pass the NONCE to the backend
  3. If the customer does not already exist, create it via REST API
  4. Use the Nonce to add a card to the customer getting a card_id via REST API
  5. Charge the card_id (via REST API) for the initial transaction.
  6. When subscription expires and/or a backend charge is to be made, use the card_id to perform a payment transaction via the REST API.

The missing piece is a verifyBuyer() method in the REST API. Seems that a possible implementation would be that when a card is saved (verifyBuyer Intent == “SAVE”) that the verification of the buyer is then complete and further use of that secure card_id will indicate that the buyer has been verified.