thegoldenrule_api

[nimble epoch]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1417589019398639749

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[dry isle]

Hello
What exactly happens when you run following step in the fixture?

{
      "name": "payment_page_confirm",
      "path": "/v1/payment_pages/${checkout_session:id}/confirm",
      "method": "post",
      "params": {
        "payment_method": "${payment_method:id}",
        "expected_amount": 3000
      }
    }

after making your subscription mode specific changes to the fixture?

[bronze hinge]

Ah, turns out I introduced an error in that call. Now works. Thanks for the quick response!
One quick follow up question since it's the next step toward getting to the full flow I need to test. Is it possible to handle both shipped and subscription products in the same checkout flow? For example, an order where they are shipped a physical product that comes with an online subscription. I don't know where to add the shipping details given that a checkout in subscription mode does not accept payment_intent_data (per the sample referenced above).

[velvet atlas]

👋 changing of the guard, i'm taking over for hanzo, just getting caught up

https://docs.stripe.com/payments/collect-addresses
When creating the Checkout Session in Subscription mode you should be able to pass shipping_address_collection

The shipping address should then be available in the payload of checkout.session.completed

[bronze hinge]

yes, I can, and that appears to work in my UI using the embedded checkout. However, I'm wondering how I supply the shipping address via API calls during integration testing. Any ideas? Unless I missed it, I can't seem to find any docs on where/how to add the address itself when simulating checkout.

[velvet atlas]

testing, one moment

[velvet atlas]

appreciate the patience, seems like this may not be possible via a fixture

This is probably why we recommend mocking API responses rather than setting up end to end integration tests

Per: https://docs.stripe.com/automated-testing

"Automated testing is a common part of application development, both for server and client-side code. Front-end interfaces, such as Stripe Checkout or the Payment Element, have security measures in place that prevent automated testing, and Stripe APIs are rate limited.
However, you can simulate the output of our interfaces and API requests using mock data to test your application behaviour and its ability to handle errors."

[bronze hinge]

Ah, ok. Part of this exercise, in addition to integration testing, was to obtain the actual API responses for mocking rather than manually constructing them (to save time and reduce errors).

FYI, it seems collecting the shipping address is possible using a fixture. Or, at least I got it to work by inspecting the traffic from a manually completed session and applying it to the payment page confirmation call. For example:

{
      "name": "payment_pages_confirm",
      "path": "/v1/payment_pages/${cs_test:id}/confirm",
      "method": "post",
      "params": {
        "payment_method": "${pm_test:data.0.id}",
        "expected_amount": 1000,
        "shipping": {
          "name": "Joe Test",
          "address": {
            "line1": "123 Main St",
            "city": "Springfield",
            "state": "IL",
            "postal_code": "62704",
            "country": "US"
          }
        }
      }
    }

I don't know if that's "approved" or not, but seems to work with the collected information flowing through the other API objects I'm interested in (invoice, checkout session, etc.). We'll see if this applies to the mixed case as well.
Interestingly, there doesn't appear to be robust input checking on data coming from the fixture. In other words, it's not possible to complete a checkout in the UI without supplying an address, yet a direct confirmation via a fixture completes without it.

[dapper light]

Hi there,
taking over for my colleague who had to step away.

When you say you can not confirm a Checkout Session without an address in the UI, what do you mean? Normally checkout session only asks for address that is necessary for calculating tax etc. Which is basically limited to zip and country in most cases.

[bronze hinge]

I have a product for which shippable: true, which triggers the checkout to collect a full address (as intended).

[dapper light]

Ok, and in your fixture you are supplying the shipping address, correct?

[bronze hinge]

Yes, that’s correct, using the payload described above.

[dapper light]

Maybe I still misunderstand your statement. So in both cases you do supply an address, correct? Sorry for all those questions. Just want to make sure we are on the same page.

[bronze hinge]

I don't know what you mean by "both cases". If what you mean is both when confirming checkout manually via the UI and programatically via a fixture, then yes. The only difference is that that UI rightly requires the full address while the API interaction does not (the payment page can be confirmed without supplying a shipping address). I was giving you guys a heads up since it seems data correctness is being enforced on the UI, but not the backend which is a known anti-pattern in system design - maybe a bug that someone somewhere would want to fix at some point and one that likely hints at other vulnerabilities.

[dapper light]

Oh I see. Thanks for the feedback. I will definitely forward the information to the product team.

[bronze hinge]

No problem and thanks for the excellent support from the entire chain here. Quite helpful given the flexibility and breadth of the API.

[dapper light]

No worries. We are always happy to help!

[bronze hinge]

Also, way better than the AI on the website which repeatedly gives wrong answers. That thing is damn near useless for anything beyond super basic.