definitely not trying to use another processor. just trying to get around Square’s restrictions as i see them (or learn that i’m wrong 
)
use case: customer wants to purchase Item A. they love to get it every monday for the office, either delivered or ready for pickup. instead of ordering every sunday in advance, they’d like to “subscribe” to a recurring weekly order. not of some generic Item A though, it’s the variant and modified one that they specifically get (and the same fulfillment as last time, i.e. delivered to Acme Corp at 10a).
what i had hoped to do was get an order created or paid webhook, see that they chose a Weekly modifier, and then stash that into our system to be cloned and paid according to whatever schedule they chose, in this case every week.
the cloning would, ideally, carry the customer, their payment source, and order fulfillment info forward into the next one and voila!
since i can’t do anything programmatically w the Checkout form it sounds like i’ll have to create our own checkout form via the SDK to facilitate this. is that right?
if so, then my thoughts go to:
- after their one-off order, when we see there was the
Weeklymodifier, we send them an email saying they have to confirm their recurring order. the link would take them to a new SDK-based checkout form that does all the above work i’d mentioned, except it’d have the original orderId stashed in the URI or something so that it would know to a) not charge them now bc they just paid, b) associate these recurring orders w that original one - from the Square Online Checkout form pop them over to this SDK form so that they only have to enter their information once instead of in a follow up process.
either way introduces friction of some sort unfortunately :\
does that make sense overall?