#mochihealth

1 messages · Page 1 of 1 (latest)

quaint minnowBOT
vast sedge
#

Yeah I can take a look - is there something in particular you need me to focus on?

proper ruin
#

so I think this is the case when the customer tries to manually verify their bank account

#

#1 have they attempted to verify it yet

#

also i notice that the subscription is marked as incomplete but when they do the verification as part of the checkout process the subscription is marked as active. why is that

#

also this kind of seems to be an edge case when dealing with ach debit payments so what would you suggest to be the best way to deal with this

vast sedge
#

As far as I can tell they haven't attempted to verify yet (the microdeposit hasn't even hit their account yet since it can take 1-2 business days to show up)

#

Can you clarify where in the verification process they see the subscription marked as active?

proper ruin
#

no they dont see it as active

#

I'm saying that if they go through the normal flow where they verify their bank account without the microdeposit then the subscription is marked as active even though the payment hasnt gone through. I was wondering why its different in this case and also if i can turn off microdeposit verification when trying to pay as opposed when trying to set up a payment intent

vast sedge
#

Ahhh I see what you mean now - you're talking about differences you see when the bank account went through instant verification vs the microdeposit verification, right?

proper ruin
#

yea

vast sedge
#

Yeah so that's because with instant verification the underlying payment intent would immediatley begin processing - at that point we move the subscription to active

#

WIth the microdeposit flow we can't even begin the payment process until the verification is done, so it stays incomplete until verification is done

#

I think there's a way to disable the microdeposit flow, but let me double check

#

Since you're using subscriptions you'll want to use payment_settings.payment_method_options.us_bank_account.verification_method and set that to instant

proper ruin
#

thank you so much

#

but im still confused about this invoice because it says that the payment attempt failed

#

in one of the events

#

but I thought they were using micro deposit verification with this

#

or did they not

#

?

vast sedge
#

Yeah sending invoice.payment_failed is a quirk of our API - we send both invoice.payment_failed and invoice.payment_action_required if the unerlying payment intent requires action

#

and yes, the invoice that you linked to was waiting on microdeposit verification, so it's underlying payment intent has a status of requires_action

proper ruin
#

thanks and it looks like they tried this one before in_1NcZ8KBPM36OC3gX1kPL1cct

#

did they ever try to pay because it says automatic collection was turned off and that usually only happens when a payment attempt fails if I'm not mistaken?

vast sedge
#

If you look at an invoice in dashboard you can usually tell yourself whether they attempted to pay or not - you can see in the notes at the top that the invoice was just finalized

#

no payment had been attempted yet

#

I'm not sure why auto_advance isn't on for that invoice though - let met check on that

proper ruin
#

yea thats what confused me

vast sedge
#

okay actually - for subscription creation I believe having it be auto_advance: false is the more expected outcome for charge_automatically subscriptions where collection_method: default_incomplete . This is because auto_advance is one of the things that controls automatic retries, and it makes no sense for us to turn on automatic retries until you actually attempte payment/confirm the PI for the first time.

The other invoice you initially wrote in about (in_1NcZuRBPM36OC3gXFOPGEVuk) initially had auto_advance: false when the subcsrpition was created as well. It only moved to auto_advance: true after payment was attempted and the invoice transitioned to a state where we're not waiting for the microdeposit.

quaint minnowBOT
proper ruin
#

but I thought you said the payment was not attempted?

vast sedge
#

Yeah sorry I know the wording has been confusing -

  • The invoice in_1NcZuRBPM36OC3gXFOPGEVuk that's waiting on the microdeposit had it's payment intent confirmed, but it's not actually in the processing state yet because microdeposit verification hasn't happened yet. Once it moves to processing the Subscription will be considered active. This is unrelated to how we control auto_advance - as soon as the payment intent was confirmed and transitioned to requires_action we turned on auto_advance
  • The other invoice in_1NcZ8KBPM36OC3gX1kPL1cct hasn't had it's Payment Intent confirmed yet so it's still has auto_advance: false