fix(wire-contract): dropoff_latitude was serialized as dropoff_latitiude

[tomas-amaro]

What this is

RideTicketLineItem.DropoffLatitude serialized as dropoff_latitiude — a transposition — from the field's introduction until now. It should be dropoff_latitude.

One line of production code, plus a regression test.

Why the correct spelling is dropoff_latitude

• Both OpenAPI specs declare it. riskified_openapi_preauth.json and riskified_openapi_postauth.json each define dropoff_latitude on the ride line item, with a description ("The latitude part of the dropoff location coordinates.") and an example. The transposed spelling appears in neither, nor anywhere else in the API reference export. It is also what the public reference documents.
• It occurred exactly once in this repository, with no test covering it.
• pickup_latitude (:89) and dropoff_longitude (:104) in the same class are spelled correctly. There is no rationale that explains the asymmetry.
• The Java, PHP and JavaScript SDKs all derive the correct spelling. This SDK was the only one in the fleet sending the wrong key.

Please confirm before merging

Whether the platform accepts, or has been accepting, dropoff_latitiude is not verified here. Nothing in this repo or the spec export answers it, and it decides how this ships:

• If the platform only ever accepted dropoff_latitude, then .NET's ride dropoff latitude has never arrived — every other field on the line item did, so this would have looked like merchants simply not sending it. Merging is a straight bug fix and needs no coordination.
• If the platform grandfathers the transposed key from .NET callers, merging silently moves the value from a key the platform reads to another key the platform reads — still correct, but worth confirming the ingestion side handles both before release notes go out.
• If the platform only accepts the transposed key and the specs are the thing that is wrong, this PR is the bug and should be closed. That would also mean Java, PHP and JS have never delivered the field, which makes it the least likely of the three.

A single request per environment with both keys populated settles it.

Context

This came out of a wire-contract parity review across the SDK fleet. The corpus driving that review had concluded the opposite — that the transposition was the live wire name, because this SDK sends it — and three SDKs had draft PRs open to adopt the misspelling. That inference was circular: drawn from this attribute, then confirmed by re-reading it. Those PRs have been reverted and the corpus corrected:

• Riskified/java_sdk#218
• Riskified/php_sdk#101
• Riskified/javascript_sdk#3
• corpus: Riskified/sdk-orchestrator (docs/flows/, docs/parity/FLEET.md)

Tests

Riskified.SDK.Tests/Model/OrderElements/RideTicketLineItemTests.cs — the dropoff latitude specifically, and all four ride geolocation names together. Asserted in both directions: the transposed key must be absent, not merely the correct one present. Verified to fail against the previous attribute and pass with it. Serialization settings mirror HttpUtils, following the existing WalletPaymentDetailsTests.

Full suite: 47 passed, 0 failed.

🤖 Generated with Claude Code