FloPay SDK Changelog

v1.11.2 - Clearer wallet confirmation failures and capture method in custom layouts #

Rejected Apple Pay and Google Pay confirmations now report a bounded cause in technical-error telemetry, and wallets in custom checkout layouts declare the session's capture method.

When Stripe rejects an Apple Pay or Google Pay confirmation as an invalid request, the technical-error telemetry event now says which kind of rejection it was. Operators can tell a mismatch between the wallet's payment form and the payment apart from a payment that changed state before the wallet returned, without collecting raw provider messages or payment details.

What changed

• Bounded cause for rejected wallet confirmations. A wallet confirmation reported with errorCode CONFIGURATION_INVALID now carries one reason:
  • deferred_contract_mismatch: the wallet's payment form did not match the payment or setup the billing API created.
  • intent_unexpected_state: the payment or setup was no longer in a state that could be confirmed when the wallet returned.
  • invalid_request: any other request Stripe rejected as invalid.
• Codes are unchanged. errorCode and failureCategory stay the same for every wallet confirmation failure, and provider runtime failures still carry no reason. Any other reason value is still reported as unknown.
• Capture method in custom layouts. When SplitCardForm is rendered inside the checkout provider without its session prop, Apple Pay and Google Pay now declare the capture method of the checkout session, as they already did for its future-use setting. Manual-capture sessions no longer present the wallet as an automatic-capture payment.

Developer notes

No change is required for standard checkout integrations. Telemetry consumers should accept the three new reason values on technical-error events.