0

I use commerce for subscriptions. We design a twig page to show subscriber's payment history.

For some reasons, the very last purchase don't show as we need to perform a "refresh-payments" (From commerce\controllers\SubscriptionsController actionRefreshPayments function) exactly like the one on CP. (See image).

But obviously, we want the user to see immediately his latest purchase without adding such a button. I don't understand where are actual data located and what makes the refresh button to get the latest purchase available from now on, but at least I'd like to perform the refresh before the page is shown.

So before searching any deeper, I wonder if there's a way I can perform that call in twig. (I'm a back-end php guy, learning how to reproduce behavior in twig). enter image description here

Improve this question
5
  • I may not understand the use case exactly—but I think the issue might just be a product of how Subscriptions work in Stripe? Invoices are by nature asynchronous, so you can't really "know" when a payment or invoice will show up here… as such, when someone signs up, they may not see the first payment until a webhook is emitted, at which point Commerce will log it. "Refreshing" before that happens I don't think will guarantee a new invoice will show up! Can you confirm that you have webhooks configured?
    – August Miller
    Jan 6 at 20:32
  • At this point, we manage to get a subscription and send it to Stripe. I goes thru. But if a user wants to immediately see it in the history, we need to add a form with a button and add this hidden field ( name="action" value="commerce/subscriptions/refresh-payments" ). If I look at the controller, what it does, it find the Gateway and perform a refreshPaymentHistory to this Gateway. I want to perform it before I show the page, the get the latest lines from Stripe.
    – Sylvain Tremblay
    Jan 6 at 20:41
  • Sure, that much makes sense! Unfortunately, way the archaic payment processing technology that Stripe (mostly) abstracts away works, the assumption has to be that transaction settlement may take an indefinite amount of time (i.e. 1 second or 1 hour). 3D Secure and other auth processes further complicate this—but it all boils down to there being no guarantee even if you manually call refreshPayments that the expected transaction will be posted yet. 😔
    – August Miller
    Jan 7 at 3:25
  • …that said—looks like Commerce exposes this via the gateway? Assuming you have a reference to the Subscription already, you might try: {% do subscription.gateway.refreshPaymentHistory(subscription) %}
    – August Miller
    Jan 7 at 5:31
  • @AugustMiller Thank you. That's exactly what I needed. And thanks for all clarification about settlement time, I will keep this in mind.
    – Sylvain Tremblay
    Jan 7 at 13:56

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.