Using a fixed_amount in Checkout for shipping causes version error

[airjoshb]

Describe the bug

When describing shipping_options in a Stripe::Checkout::Session.create call in Checkout, using "type: 'fixed_amount'" triggers the following error,

Received unknown parameter: v1

When looking through the code, I found the issue in testing, which looks like it is appending "v1" to the url

To Reproduce

Add a "fixed_amount" type to shipping_rate_data in a create Checkout session call

Expected behavior

We should get the fixed amount information as an option.

Code snippets

should "Test shipping rates post" do
      Stripe::ShippingRate.create({
        display_name: "Sample Shipper",
        fixed_amount: {
          currency: "usd",
          amount: 400,
        },
        type: "fixed_amount",
      })
      assert_requested :post, "#{Stripe.api_base}/v1/shipping_rates"

---

Update 3:50pm PST: It appears that this error is triggered when more than one shipping_rate_data is described in a hash.

---

OS

macOS

Language version

ruby 3.2.5

Library version

13.1.1, 13.1.0

API version

2024-10-28.acacia

Additional context

No response

[remi-stripe]

@airjoshb Can you share the exact code you are using end-to-end to reproduce this? The code you shared looks like part of our Test suite so I'm not really grasping what the bug is

[airjoshb]

Sorry for the confusion @remi-stripe, I was using the test code to point out where the v1 error was coming from. Here is my code and I suspect it is some sort of syntax change from a previous version as it was working before I did a long overdue upgrade.

checkout_session = Stripe::Checkout::Session.create({
      line_items: line_items,
      mode: mode,
      customer_creation: customer_creation,
      allow_promotion_codes: true,
      phone_number_collection: {
        enabled: true
      },
      shipping_address_collection: {
        allowed_countries: ['US'],
      },
      shipping_options: [
        {
          shipping_rate_data: {
            type: 'fixed_amount',
            fixed_amount: {
              amount: 500,
              currency: 'usd',
            },
            display_name: 'Local Delivery or CA Ship',
            delivery_estimate: {
              minimum: {
                unit: 'business_day',
                value: 1,
              },
              maximum: {
                unit: 'business_day',
                value: 2,
              },
            },
          },
        },
        {
          shipping_rate_data: {
            type: 'fixed_amount',
            fixed_amount: {
              amount: 1100,
              currency: 'usd',
            },
            display_name: 'Ship outside CA',
            delivery_estimate: {
              minimum: {
                unit: 'business_day',
                value: 2,
              },
              maximum: {
                unit: 'business_day',
                value: 3,
              },
            },
          },  
        }
      ],
      consent_collection: {
        promotions: 'auto',
      },
      custom_fields: [
        {
          key: 'pickup',
          label: {type: 'custom', custom: 'Pickup Location'},
          optional: true,
          type: 'dropdown',
          dropdown: {
            options: 
              shipping
          },
        },
      ],
      success_url: cart_success_url,
      cancel_url:  cart_cancel_url,
    })

[remi-stripe]

The code you shared isn't sufficient to reproduce unfortunately. Multiple of those lines reference variables that aren't set first so I am not sure how to reproduce. I tried similar code on my own account with 13.1.0 and it does work as expected and doesn't error about the /v1/ part.

My gut says that the code erroring is not what you think it is, that Checkout Session creation works properly and something else in your code is erroring or failing. Can you try and provide a really simple end to end reproduction script with clear logs showing which part is crashing.

I did look into our logs and I see some requests where the parameters look like this:

  success_url: "<redacted>",
  v1: {
    0: {
      shipping_rate_data: {
        ...
    },
    1: {
      shipping_rate_data: {
        ...
      },
    },
  },
}

So right now it does look like your own code is passing a parameter/hash named v1 instead of the word shipping_options

[airjoshb]

I hear ya, @remi-stripe, however, if I replace this block,

shipping_options: [
        {
          shipping_rate_data: {
            type: 'fixed_amount',
            fixed_amount: {
              amount: 500,
              currency: 'usd',
            },
            display_name: 'Local Delivery or CA Ship',
            delivery_estimate: {
              minimum: {
                unit: 'business_day',
                value: 1,
              },
              maximum: {
                unit: 'business_day',
                value: 2,
              },
            },
          },
        },
        {
          shipping_rate_data: {
            type: 'fixed_amount',
            fixed_amount: {
              amount: 1100,
              currency: 'usd',
            },
            display_name: 'Ship outside CA',
            delivery_estimate: {
              minimum: {
                unit: 'business_day',
                value: 2,
              },
              maximum: {
                unit: 'business_day',
                value: 3,
              },
            },
          },  
        }
      ],

with

shipping_options: [ { shipping_rate: "shr_XXXXXXLHQPVTKPLFvTR5lA1s" }],

It works perfectly fine, so there doesn't seem to be another place where v1 is being passed except by the url the gem is posting from.

[remi-stripe]

@airjoshb Can I ask you to share an exact script to reproduce this? Your earlier example had local variables that don't exist. Unfortunately without a clear repro I'm coming up empty right now on what could cause this. Feel free to use the default API key we use in our docs: sk_test_4eC39HqLyjWDarjtT1zdp7dc so that we can run the exact same code.

[helenye-stripe]

This is fixed in the newest release, v13.1.2.

[airjoshb]

Sorry, @helenye-stripe. I didn't see your reference to the fix. Thanks!

[remi-stripe]

@airjoshb yeah sorry for the confusion. We ended up figuring out the root cause while diving into the internals of the SDK and a change we made a while ago! Thanks a lot for the report, this could have gone unnoticed for a while otherwise!