runefarer

[buoyant cypress]

But, sometimes, I'm getting a strange error: 'The object cannot be accessed right now because another API request or Stripe process is currently accessing it...'
Hi there!
Can you share the ID (req_xxx) of the failing API request?
https://support.stripe.com/questions/finding-the-id-for-an-api-request

[vivid mason]

One thing to add is that I'm using test keys right now, as I'm not in the US and it's almost impossible to test live with actual Cash App. At least until someone from the US external team wakes up...

[buoyant cypress]

But in general this seems to be a concurrency issue in your integration, like accessing and modifying the object in the same time by your integration

It works... as long as we ignore webhook events. Immediately after creating a subscription, I'm getting a invoice.payment_failed event.
Can you share the event Id ?

[vivid mason]

That's hard to do, because it's rare and I didn't personally get the error.

Maybe we can address the second issue first?

[buoyant cypress]

yes of course

Can you share an event Id for the second one ?

[vivid mason]

Yeah, here it is: evt_1NqCplCzutyAyCBFnIJNqmsR

[buoyant cypress]

Is there a particular reason for using the custom API (confirmCashappPayment) with Subscription ?

Because the recommended options are listed here:
https://stripe.com/docs/billing/subscriptions/cash-app-pay

[vivid mason]

That's just extending on top of our card flow.

[buoyant cypress]

Make sense. Because the cause of the failure is:

This PaymentIntent requires a mandate, but no existing mandate was found. Collect mandate acceptance from the customer and try again, providing acceptance data in the mandate_data parameter.

You should update your integration and use Stripe Element in order to cover all these use cases (CashApp with mandate, Card payments...)

You can use Stripe Element with SetupIntent or direct Subscription APIs

[vivid mason]

We currently don't have the bandwidth to do that with this task right now.

I'm sure we can make this work.

In the link you shared, there's a tab for using the Subscriptions API. What should I do after I get to the second step, create a subscription, and send the client secret to the frontend?

Or, how to use mandate with Cash App?

[buoyant cypress]

You have two options:

1. use SetupIntent: https://stripe.com/docs/payments/cash-app-pay/set-up-payment in order to collect the PayentMethod

So that you collect a mandate when saving the PaymentMethod

2. use Subscription API, yes as mentioned in that tab:
   https://stripe.com/docs/billing/subscriptions/cash-app-pay#pi-confirm-payment
   So you create a subscription with default_incomplete behavior send the client_Secret to your fontend

And then confirm the payment in your server by passing the mandate_data
https://stripe.com/docs/billing/subscriptions/cash-app-pay#pi-confirm-payment

[vivid mason]

Yeah, that's the question, since we need to determine on the client side whether to redirect (mobile) or show the QR code, we need to confirm the payment intent on the client side.

Or, are you suggesting to do an initial payment confirm on the server side immediately after creating the subscription, with mandate data, and then just pass the result to the client side to do what it should?

[vivid mason]

Because, if we're doing the confirm on the server side, what's the point of sending the client secret to the client side?

[buoyant cypress]

The client side if to collect the payment (QRcode thing) and the server side is for acknowledgingacknowledging the mandate_data (user-agent/IP)

[vivid mason]

Okay, so I'm seeing:
On the server:

1. Create Subscription
2. Confirm Payment Intent immediately after with mandate
3. Send client secret to client

On the client side:

1. Use confirmCashappPayment to get QR code next action? Or just retrievePaymentIntent?

[buoyant cypress]

The order is not correct, you need to follow exactly the guide I shared with you:
https://stripe.com/docs/billing/subscriptions/cash-app-pay

1. Create Subscription
2. Send client secret to client and confirm the payment on frontend
3. Confirm Payment Intent on the server side after with mandate

[vivid mason]

But the second step triggers the failed event before we can get to step 3.

[buoyant cypress]

Yes that's expeced, you can drop that event in your integration, and complete the payment with step 3.

[vivid mason]

No, we want to listen to invoice.payment_failed events

From what I gather, we can skip using confirmCashappPayment on the frontend and just call our own server API to confirm the payment intent with mandate data.

[wind gale]

you can listen to them but ignore(respond to the webhook with a 200, but do nothing else) if the billing_reason on the Invoice is subscription_create.

[vivid mason]

In that case, do we even need to go through the mandate confirmation process?

We can continue calling confirmCashappPayment and ignore the event if the reason is subscription_create.

[wind gale]

well the mandate is required for the payment to succeed

[vivid mason]

Doesn't confirmCashappPayment create the mandate? You'd think it would, since it's specifically for Cash App.

[wind gale]

I've never looked at this payment method before, I don't understand why we ask you to confirm a PaymentIntent on a backend server manually passing mandate acceptance, instead of using our frontend stripe.js library that would do the confirmation/pass the mandate acceptance, but I suppose there is a reason for it

[wind gale]

that's what I'd think yep

[vivid mason]

I didn't want to confirm on the server side, that's what @buoyant cypress suggested. https://stripe.com/docs/billing/subscriptions/cash-app-pay

[wind gale]

to me the guide makes no sense and instead the step 3 you would confirm on the client side

[vivid mason]

Yep

That's what we've been doing.

Only wrench in the works is the invoice.payment_failed event.

[wind gale]

does using billing_reason to filter solve that?

[vivid mason]

It should, I don't think with cards you'd get payment failed on subscription create, would you?

[wind gale]

it would depend if you're using payment_behavior:"default_incomplete" . But in general likes yes, a payment failure can happen on the first Invoice of a subscription

generally I would tell people to ignore them in webhooks since usually you have logic there for "retrying" or "cancelling" the subscription since you assume the event means a recurring payment failed; but for the first Invoice you're going to be handling those failures directly in yorur frontend with the customer