- Fix ios billingDetails #592
- Fixed compilation error for 8.0.0.beta9 due to fpx issue #628
- Upgrade tipsi-android to 1.4.6 #563
- Fix build on xcode 11.4 #563
- Compile SDK Version increased from 26 -> 28
- Target SDK Version increased from 26 -> 28
- Min SDK Version increased from 16 -> 19
- Support libraries increased from 27.1.0 to 28.0.0
stripe-android
upgraded from 8.1.0 to 10.4.0
- Minimum compatible
stripe-ios
sdk -> 16.0.7, but recommended 17.0.1 or later (update yourPodfile
or vendoredstripe-ios
!) - Xcode version: recommended 10.3.1 or later
stripe.createPaymentMethod(…)
stripe.confirmPaymentIntent(…)
stripe.confirmSetupIntent(…)
stripe.authenticatePaymentIntent(…)
(only used with manual confirmation mode)stripe.potentiallyAvailableNativePayNetworks(…)
- Breaking The Card form now returns a PaymentMethod. The Card form will no longer return a token (or Source)
- Warning Supports React Native 59.x (other versions at your own risk)
- JSDoc-annotated API Descriptions for the new APIs
- Helper methods
stripe.slugForCardBrand(…)
andstripe.presentableStringForCardBrand(…)
to normalize Card Brand Strings that change values depending on which API you're working with. (Stripe API oddity)
- Prevented toErrorCode from itself causing an error
- The example app has new PaymentIntent and SetupIntent screens that can be used to test various card scenarios
- The example app requires a backend for those screens, which can be forked and one-click deployed to Heroku from:
- mindlapse/example-tipsi-stripe-backend
- You need to set the environment variable BACKEND_URL to the location it is deployed
- Added .circleci config
- Added eslint & prettier config
- Google pay: capture email
- Add translations for German, Dutch, Italian and Spanish.
- android: update CreditCardEntry:1.5.1
- Remove broken imports
- Fixed issue #232 Added card type for source creation (#261)
- Update iOS Stripe SDK to 14.0.0
- Update Android Stripe SDK to 8.1.0
- Fix unassigned promise rejector bug
- Update CreditCardEntry to 1.4.10
- Update iOS Stripe SDK to 13.2.0
- Update iOS deployment target to 9.0
- Update Android Stripe SDK to 8.0.0
- Common error codes. Part of them provided by
tipsi-stripe
, another part byStripe
itself.
paymentRequestWithAndroidPay
now supports booleanphone_number_required
field to ask a user for phone number
tipsi-stripe
now respects project-level GMS version on Android
From this release we are starting unify our Public API.
There was a difference between iOS and Android API, now we've created new methods that currently work as a proxy.
So, we have marked deprecated methods inside src/Stripe.js
, and yes there is no more Stripe.${platform}.js files.
But, you won't see any changes. Breaking changes will be introduced in version 6.
deviceSupportsAndroidPay
anddeviceSupportsApplePay
=>deviceSupportsNativePay
canMakeAndroidPayPayments
andcanMakeApplePayPayments
=>canMakeNativePayPayments
paymentRequestWithAndroidPay
andpaymentRequestWithApplePay
=>paymentRequestWithNativePay
completeApplePayRequest
=>completeNativePayRequest
(Android implementation doesn't exist)cancelApplePayRequest
=>cancelNativePayRequest
(Android implementation doesn't exist)openApplePaySetup
=>openNativePaySetup
(Android implementation doesn't exist)
As you can see all platform specific methods are now unified.
We called them Native Methods
because Google/Android Pay
and ApplePay
are native payments systems unlike Credit Cards.
Stripe.ios.js
andStripe.android.js
=>Stripe.js
- Native iOS
TPSStripeManager
renamed toStripeModule
- Example App now uses new unified methods
REACT_CLASS
for Native Android implementation of PaymentCardTextField renamedCreditCardForm => TPSCardField
PaymentCardTextField
merged into one compoment. It's a first step to clearing the difference between iOS and AndroidAndroid Pay => Google Pay
inandroid/src/main/res/values/strings.xml
prop-types
in example updated15.5.10 => 15.6.1
, appium1.8.0 => 1.8.1
- Default string value for Cancel button in Card Form
gettipsi_card_enter_dialog_negative_button
- Support
overflow
style property on PaymentCardTextField (now it has wrapper inside)
- Obsolete AndroidPay flow
- Added missing
{number|expiration|cvc}Placeholder
fields to iOS'<PaymentCardTextField />
- Removed
package.json
from tipsi-stripe's podspecpreserve_paths
(to enable adding this pod via a:git
key without hitting npm/yarn considering it a js package)
- Fixed int LOAD_PAYMENT_DATA_REQUEST_CODE in GoogleApiPayFlowImpl.java (< 65535)
- Fixed an error with PropTypes
- Method
stripe.canMakeAndroidPayPayments()
checks if gpay supported and user has existing payment method
- Method
stripe.deviceSupportsAndroidPay()
doesn’t require anymore user to have existing payment method
- Method
deviceSupportAndroidPay()
now also checks if google pay has at least one existing payment method (for example user attached his card before)
before 5.0.0:
// somewhere in the app start section
stripe.init({
merchantId: '<MERCHANT_ID>',
publishableKey: '<PUB_KEY>',
androidPayMode: 'test',
})
stripe.paymentRequestWithAndroidPay(paymentOptions)
after 5.0.0:
// same as above except used method name
stripe.setOptions({
merchantId: '<MERCHANT_ID>',
publishableKey: '<PUB_KEY>',
androidPayMode: 'test',
})
stripe.paymentRequestWithAndroidPay(paymentOptions)
// somewhere in the app start section
// make sure you've set androidPayMode before using androidPay related methods i.e.
// stripe.deviceSupportsAndroidPay()
// stripe.paymentRequestWithAndroidPay()
// or runtime exception will be thrown
stripe.setOptions({
androidPayMode: 'test',
})
// somewhere else later i.e. near store cart code
stripe.setOptions({
publishableKey: '<PUB_KEY>',
})
// make sure you've set *all* needed options before, both androidPayMode and publishableKey
// or exception will be thrown
stripe.paymentRequestWithAndroidPay(paymentOptions)
before 5.0.0:
// you couldn't before set billing_address_required, shipping_address_required options
// to require user filling that data. shipping_address_required was true by default
// and such data was missing in the method response (useless user input)
stripe.paymentRequestWithAndroidPay(paymentOptions)
after 5.0.0:
// explicitly set required input from user by
// setting billing_address_required, shipping_address_required props,
// omitted values are false by default
const addressRequirements = {
billing_address_required: false,
shipping_address_required: true,
}
stripe.paymentRequestWithAndroidPay({
paymentOptions,
...addressRequirements,
})
- Modern GooglePay api was used by default
shippingContact
,billingContact
appear are in results ofpaymentRequestWithAndroidPay()
- Firebase dependency appears
- More strict runtime argument checks
- Method
setOptions()
performs multi-step initialization and used instead ofinit()
. OptionspublishableKey
,androidPayMode
are settable at runtime. If method requires presence of options that are unset, runtime exception will be thrown. Special case:androidPayMode
re-init is forbidden and leads to runtime exception. - Wallet api version bump
- AndroidPay flow extracted from
StripeModule
- Better naming
- Only create api client on demand
- Extract commons to utils
- Avoid copy and paste in old code
- Obsolete AndroidPay flow is disabled by default and will be removed soon
- Fix of Android Pay Shipping address not working
- Avoid
StripeModule
Activity NPE - Avoid bugs regarding options default values
- Fix leaked promise bug