fix(payment): map phone, carrier, and trackingNumber in shippingDetails by reginaldalfret · Pull Request #2752 · stripe/stripe-react-native · GitHub
Skip to content

fix(payment): map phone, carrier, and trackingNumber in shippingDetails - #2752

Open
reginaldalfret wants to merge 2 commits into
stripe:masterfrom
reginaldalfret:fix/issue-1959-shipping-details-phone-carrier
Open

reginaldalfret wants to merge 2 commits into
stripe:masterfrom
reginaldalfret:fix/issue-1959-shipping-details-phone-carrier

Conversation

@reginaldalfret

Copy link
Copy Markdown
Contributor

Summary

Fixes #1959.

When confirming a PaymentIntent with \shippingDetails, only the recipient
ame\ and \�ddress\ were being mapped to the native payment intent shipping parameters on both Android and iOS. As reported in #1959, any provided \phone, \carrier, or \ rackingNumber\ fields were omitted from the Stripe API request.

Changes

  • Android (\�ndroid/.../Mappers.kt): In \mapToShippingDetails, forward \carrier, \phone, and \ rackingNumber\ to \ConfirmPaymentIntentParams.Shipping.
  • iOS (\ios/Mappers.swift): In \mapToShippingDetails, set \carrier, \phone, and \ rackingNumber\ on \STPPaymentIntentShippingDetailsParams.
  • TypeScript (\src/types/PaymentMethod.ts): Expand \ShippingDetails\ to optionally include \carrier\ and \ rackingNumber\ in addition to \BillingDetails\ fields.
  • Unit Tests: Added test cases for \mapToShippingDetails\ with carrier, phone, and tracking number in both \�ndroid/.../MappersTest.kt\ and \ios/Tests/MappersTests.swift.

Test Plan

  • Ran \gradlew detekt\ in \�ndroid/: PASS
  • Verified TypeScript type definitions match native param shapes.

When confirming a PaymentIntent with shipping details, only the name and
address fields were being mapped to the native payment intent shipping
parameters on Android and iOS. This caused carrier, phone, and tracking
number to be silently dropped from the request payload sent to Stripe.

Update mapToShippingDetails on Android (Mappers.kt) and iOS
(Mappers.swift) to extract phone, carrier, and trackingNumber, update the
TypeScript ShippingDetails definition to include these optional fields,
and add unit tests for both platforms.

Fixes stripe#1959

Signed-off-by: reginaldalfret <reginaldalfret@gmail.com>
@reginaldalfret
reginaldalfret requested review from a team as code owners October 19, 2026 09:01
@jaynewstrom-stripe

Copy link
Copy Markdown
Collaborator

- Use safe calls on nullable result in mapToShippingDetails test in MappersTest.kt
- Update etc/stripe-react-native.api.md with new ShippingDetails properties (carrier, trackingNumber)

Signed-off-by: reginaldalfret <reginaldalfret@gmail.com>
@jaynewstrom-stripe

Copy link
Copy Markdown
Collaborator

@ratomirjovanovic ratomirjovanovic left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case it helps get this unblocked: in the latest run of "Check public API surface", the only remaining difference is not in your change. The regenerated report drops one // (undocumented) line above style?: StyleProp<ViewStyle>; in the platform pay button props (around line 3568 of etc/stripe-react-native.api.md), while the new ShippingDetails_3 entry already matches. So rebasing on main and regenerating the report (yarn api-extractor run --local, or copying temp/stripe-react-native.api.md over the committed file as the warning suggests) should clear that check.

One small thing on the type: ShippingDetails is now BillingDetails & { carrier?; trackingNumber? }, so it still accepts email, which neither ConfirmPaymentIntentParams.Shipping nor STPPaymentIntentShippingDetailsParams has, and it is dropped without a warning. Omit<BillingDetails, 'email'> would make that visible at compile time, though it is arguably out of scope here.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

confirmPayment not sending full billingDetails and shippingDetails (missing carrier and phone)

3 participants