SEC-768: Send card details to Stripe in the request body, not the URL

[msuitcase]

Description

ReferralCustomer.addCreditCard builds the POST https://api.stripe.com/v1/tokens request with card[number], card[exp_month], card[exp_year] and card[cvc] in the URL query string, with an empty request body. Query strings are routinely captured by access logs, outbound proxies, APM/tracing tools and Referer headers, so cardholder data could be retained outside the payment path (PCI DSS requirement 3 / 4).

This change sends the same form-encoded fields in the request body instead. Stripe already expects application/x-www-form-urlencoded bodies on this endpoint (it is what easypost-ruby, easypost-go and easypost-csharp do today), so there is no behavioural change for callers.

Also adds a Next Release CHANGELOG entry.

Tracking: SEC-768 (internal).

Testing

• npx eslint src/services/referral_customer_service.ts, npx prettier --check, and a full tsc pass all succeed locally.
• Cassette re-record needed: test/cassettes/ReferralCustomer-Service_*/add-a-referral-user-credit-card_*/recording.har was recorded with the card fields in the URL, and Polly matches on URL and body, so add a referral user credit card will not replay until it is re-recorded with PARTNER_USER_PROD_API_KEY / REFERRAL_CUSTOMER_PROD_API_KEY. I do not have those keys. When re-recording, please confirm the new recording no longer contains the test card PAN/CVC in the URL (the current HAR does) and that the body scrubber covers the form fields.

Pull Request Type

Please select the option(s) that are relevant to this PR.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Improvement (fixing a typo, updating readme, renaming a variable name, etc)

🤖 Generated with Claude Code