Release Notes

Light bulb Highlights

Note: Upgrading to this version will necessitate adjustments to functionality and UX. 

Please ensure that these modifications are adequately addressed during integration.

For comprehensive details, please refer to the release notes below and the CoinBridge Product documentation.

| Global – iOS & Android SDK Updates

  • Providing full support for different service (Card) statuses (Active / Not Active).

| Android SDK

  • Providing future support for multiple wallet types (Application wallet / Google Wallet*).
  • Providing full provisioning status per wallet (Available / Active / Not Active).
  • Bug fixes.
| iOS SDK:
  • Providing full support for different Apple wallet types (iPhone / Watch).
  • Providing full provisioning status per wallet (Available / Active / Not Active).
  • Sandbox environment – Supporting provisioning for “Watch” wallet.
  • Bug fixes.

|*Google Wallet – This wallet type will be supported in the near future.

Light bulb Details

| Supporting different service (Card) statuses (Active / Not Active)

  • The purpose of this feature is to provide the integrating application with information about the state of the service (Card).
    • Card status can be set to one of the following values:
      • Active – The card is active and can be provisioned to a wallet upon request (This is the default status of a card).
      • Not Active – The card is suspended and cannot be used or provisioned.
    • Activities which control the service (Card) status:
      • Onboarding to service – Once a user successfully enrolls in the service, the newly issued card will automatically be set to “Active.”
      • Fraudulent activity – In such cases, CoinBridge will set the card status to “Not Active”.
      • Blocking service to user – CoinBridge may set the card status to “Not Active” in response to a customer request to deny service to a specific end user.
  • In case the Card (Service) status was changed to “Not Active” by CoinBridge:
    • All Existing provisioned wallets will be automatically suspended (will be set to “Not Active”).
    • Users will not be able to use the CoinBridge service.
    • Users should be prompted to contact customer support to resolve the issue.
    • Customer support should contact CoinBridge support for more information about the specific case.
  • In case the customer wished to suspend or block a specific user(s) from using the CoinBridge service:
    • The customer support team should request CoinBridge support team to block a specific user from the service (a user-unique identifier is required for this request type).
    • CoinBridge support team will set the user’s service (card) status to “Not Active”.
    • All Existing provisioned wallets will be automatically suspended (will be set to “Not Active”).
    • The blocked or suspended user will not be able to use the CoinBridge service.
    • Blocked or suspended users should be prompted to contact customer support to resolve the issue.
  • UX suggestions for user prompt (in case card/service is not active):

 

iOS

Android

                    

iOS SDK

Supporting multiple wallet types and provisioning statuses iOS SDK only!  

The new functionality below replaces the “is_provisioned” (True/False) provisioning state indication, with a more detailed one.

  • The purpose of this new feature is to provide the integrating application with comprehensive information about the following:
    • Wallet types available for provisioning (iPhone Wallet and/or Watch Wallet).
    • Provisioning status for each available wallet:
      • Not Provisioned – the wallet is available for card provisioning.
      • Active – the card is already provisioned for this wallet.
      • Not Active – the card is already provisioned for this wallet, but the provisioned token is currently suspended and cannot be used for payment.
  • The above information will be used by the application to offer its users proper UX for the following scenarios:
    • Presenting “Pay with Apple Pay” or “Add to Apple Pay” button.
    • Presenting the actual provisioning state per available wallet.
    • Presenting an indication in case there’s an issue with one of the user’s provisioned cards.
    • Allowing a user to provision an available wallet (in case the card is yet to be provisioned).

Note: Please see comprehensive UX specifications & requirements via the CoinBridge Figma Documentation

Examples of scenarios supported by this SDK version:

 Watch Wallet is Provisioned (Active)


Watch Wallet Provisioning Status = “Not Active” 

 
Sandbox Environment – supporting provisioning flow for Watch wallet iOS SDK only!

For comprehensive information, please refer to the ‘CoinBridge iOS SDK Sandbox Guide’ document.

  • To properly test Apple Watch provisioning, the new iOS sandbox environment will support a successful provisioning flow for Apple Watch. 
  • Simulating this flow can be done by tapping the new “Watch” button.

Example from the new iOS Sandbox test application

 

 

Android SDK

 

Supporting multiple wallet types and provisioning statuses Android SDK only!  

The new functionality below replaces the “is_provisioned” (True/False) provisioning state indication, with a more detailed one.

  • The purpose of this new feature is to prepare CoinBridge SDK for native support of additional wallet types:
    • Wallet types that are available for provisioning (application wallet and/or Google Wallet).
    • Provisioning status for each available wallet:
      • Not Provisioned – The wallet is available for card provisioning.
      • Active – The card is already provisioned for this wallet.
      • Not Active – the card is already provisioned for this wallet, but the provisioned token is currently suspended and cannot be used for payment.
        • UI/UX compulsory updates – please address this scenario as if the user’s card was set to “Not Active” (refer to the first section of this release notes).
  • The above information will be used by the application to offer its users proper UX for the following scenarios:
    • Presenting “Pay with Google Pay” or “Add to Google Pay” button.
    • Presenting the actual provisioning state per available wallet.
    • Presenting an indication in case there’s an issue with one of the user’s provisioned cards.
    • Allowing a user to provision an available wallet (in case the card is yet to be provisioned).

* Google Wallet provisioning will be available soon. For now, provisioning in Android devices can only be performed for an application wallet.

 

Additional Updates and Bug Fixes

  • Android SDK:
    • Major bugs resolved – 3
    • Minor bugs resolved – 5 
  • iOS SDK:
    • Major bugs resolved – 1
    • Minor bugs resolved – 3
General Notes
  • You can access the full and updated SDK documentation using these links:
  • Android SDK 
  • IOS SDK 
 
 
 
 

Light bulb Highlights

| Android SDK

  • Reduction of unexpected errors during card provisioning flow – via new provisioning architecture (Note: includes breaking changes).
  • Improved validation of supported & unsupported devices.
  • Bug fixes.
| iOS SDK:
  • Improved validation of supported & unsupported devices.
  • Bug fixes.

Light bulb Details

| Breaking Change – New SDK “Configuration” Method (Android SDK only!)

  • The purpose of this new method is to allow the CoinBridge SDK to perform proper configuration of the wallet, prior to calling any other method.
  • Performing this new configuration flow at such an early stage will allow CoinBridge SDK to properly cope with unexpected issues during the card provisioning flow, which will take place later on.
  • Calling this method should be done each time the app is loaded (from a closed state).
  • Calling this method must take place prior to any other method.
  • In case this method isn’t called, the CoinBridge SDK will fail during Initialization (a dedicated callback error was added as well).
  • For detailed instructions about method implementation, please visit
    CoinBridge SDK v1.35.0 documentation.
| New Validation for “Pay with currently open app / foreground” Supported Device (Android SDK only!)
  • The purpose of this validation is to verify that the user’s device properly supports Tap payments done by a currently open application.
  • This validation will take place during the “Initialization” flow.
  • Today, during “Initialization” the CoinBridge SDK verifies that the user’s Android device is eligible to perform contactless payments (Android OS version, the existence of NFC feature, etc.)
  • From this version onward, we’ve added a new verification, that checks if the device can be configured to perform contactless payments, by using the currently open app (instead of always using the configured default payment method / Google Wallet).
  • In case the user’s Android device does not support this configuration, a new callback error will be returned when calling the “Initialization” method: DEVICE_NOT_ELIGIBLE_NO_FORE   GROUND_PAYMENT_SETTING.
  • In such cases, the app should inform the user that the device does not support contactless payments by the application. (Similar to other reasons for device ineligibility to use this feature – that have already been addressed via the DEVICE_NOT_ELIGIBLE error callback).

     

| Device and Terminal Communication Block in Case the Device is Not Prepared for Payment (Android SDK only!)
  • From this version onward, in case the device is not prepared for payment – this new Android SDK capability will automatically stop communication between the device and the payment terminal.
  • Background:
    In case a user taps a payment terminal, the device will automatically start communication with the payment terminal. In case the integrating application is opened and a card has already been provisioned, this will result in card token details being communicated to the payment terminal. At this time, in case the “readyToPay” callback is yet to be called by the “prepareToPay” method (the device is not ready for payment), the payment will be automatically declined by CoinBridge Servers.
  • To avoid the scenario above, while verifying that card token, details will only be communicated in case the device is ready for payment, the CoinBridge SDK will automatically stop communication or card token details.
  • In such case:
    • The payment terminal will present a “Try Again” text.
    • The CoinBridge SDK will not provide any indication to the integrating application.
  • During the following CoinBridge SDK version – CoinBridge SDK will report to the integrating application that this scenario occurred, via a new dedicated callback.
| Card Readiness Validation Upon Provision or Add to Wallet Attempt (iOS and Android SDKs)
  • From this version onward, when calling the “Card Provision” or ”Add to Apple Wallet” methods – while the issued card is not ready yet – a dedicated error callback will be called.
  • This scenario can occur in case a user’s card does exist, but card details are not yet fully ready within the CoinBridge SDK.
  • New error callback name – “Card Details Not Arrived”.
  • In such case, the application should wait until the full card details are provided through CBPaymentStatus event.

Additional Updates and Bug Fixes

  • Android SDK: 6 minor bugs resolved.
  • iOS SDK: 5 minor bugs resolved.
General Notes

Full updated SDK documentation can be found via the links: Android SDK and iOS SDK.

Light bulb New SDK Upgraded Architecture

New upgraded architecture for both our iOS and Android SDKs.

“Pre-Payment Journey” focused.

New optimized workflow for using the SDKs methods and tools.

Exposing new tools (SDK Methods) to allow better decision-making for the integrating application.

| Highlights
  • This new architecture will allow the integrating mobile application more tools, which will result in allowing a better UX for its end users.
  • The new upgrade will result a significant reduction in data & network usage.
  • The CoinBridge SDK 1.0.32 is designed to optimize the usage of its method and tools, by providing more information to the integrating application, while using less requests.
  • Significant reduction in error potential during the end-user’s pre-payment journey, especially during the card provisioing flow.
  • Highlights of this new SDK scheme can be found below.
  • Relevancy – iOS & Android CoinBridge SDKs.
| “Is Authenticated” (New Method)

This new method purpose is to allow the integrating application to quickly identify if the CoinBridge SDK is already authenticated for this user & device, or not. (True/False).

This new method should be called upon every application loads, right after the user performs authentication (login).

By using this method, we’ve significantly reduced the overall number of attempts the application has to make for authenticating the CoinBridge SDK.

In case this method returns “TRUE”, the integrating application can skip the authentication step, and move to the initialization step right away.

Notes:

  • This new behavior will replace the existing behavior (in V1.0.31) which requires to call the initialization method every time the application loads.
  • This method should be called only after end-user perform login & only for end-users that are eligible for the CoinBridge product.
| “Authentication” (Changes for Existing Method)

As part of the optimized flow, the criteria for the integrating application to use this method have been updated.

The integrating application should only call this method in case the response from the new “Is Authenticated” method = FALSE.

The Authentication method will be used prior to using the “init/initialize” (android/ios) method.

Only once the CoinBridge SDK was successfully authentication, the app should continue to the next step of calling the “Initialization” method..

Note: the above represent a switch of the order of play for the “Authentication” and the “Initialization” methods.

| “Initialization” (Changes for Existing Method)

Starting this SDK version, the “Initialization” method should only be used after successful authentication of the CoinBridge SDK.

The new and improved “Initialization” method is designed to return a callback much faster, while including additional information for the integrating application to use.

Introducing new callback structure for this method (“Has Card”):

Before this version release, upon successful Initialization, the “onInitCompleted” callback returned the “CBPaymentStatus” object – which included details of the end-user’s issued card (in case issued).

From this version onwards, the “onInitCompleted” callback will include an additional object named “Has Card” (True/False) – which will allow the application to quickly identify if the end-user was already issued a card or not.

This change will significantly improve the integrating application ability to adjust the App UI/UX to accordingly (Depending on the application configuration of manual/automated card issuing).

“CBPaymentStatus” object – This object was upgraded as well
  1. In case the payment method (Card) availability for this device at the time of Initialization completion (as part of the “onInitCallback”) is unknown, this object will be NULL.

    In such cases, the integrating application should wait to receive for full payment method information, via the“onPaymentMethodStatusChange” method (via the “CBNotificationService”).

  2. “CBCardStatus” update:

    We’ve removed the “UNAVAILABLE” enum, as in case card does not exist for this end-user. The application will know that through the new “Has Card” object (which returns together with the “onInitCompleted” callback).

    This will allow the integrating application to receive this valuable information much earlier during the pre-payment journey.

| “Provision Card” (New Method) – Android SDK only!
In order to reduce the probability of errors during the card provisioning flow, we’ve differentiated this activity from the “Initialization” flow.

Before this version release, the CoinBridge SDK automatically initiated the card provisioning flow.

From this version onwards, The integrating application will be responsible to initiate the card provisioing flow.

In context of potential implication on the UX presented by the integrating application, there is no need to perform any modifications (while please feel free to consult our Product Mgmt. Dept for more information).

Notes:
  • The application should only use this method in case the end-user already has a card (“Has Card” = True) & the card is Active (“Not_Active”) & not already Provisioned (IsProvisioned = False”).
  • Once this new method has been called, the application should wait for the “onPaymentMethodStatusChange” event via the “CBNotificationservice”, which will include an updated status of the “IsProvisioned” parameter (Updated to “True”).
  • In case this method was called, while current state of Initialization, authentication and card are not as should, a relevant error will return.
| “Logout” (Changes for Existing Method)

As in previous SDK versions, it is crucial to call the “Logout” method in case the user performs logout from her/his account.

Before this version release, in rare cases, this method might have returned an result callback, in case of an issue.

From this version onwards, we’ve transformed this method to be network agnostic. By that, completely eliminating the chance of an error.

Due to the above, the Error related callbacks & enums were removed from documentation as well.

Additional Updates and Bug Fixes

| Error Codes
  • All Error Codes lists were updated to support the new architecture.
  • New Error codes lists were added for new methods
  • Modifications were made for error codes lists of existing methods.
| Improved error handling flows

This new SDK version will include additional identifiers that returns as part of an error (in case returned). This will allow improved support investigation processes for resolving an outstanding issues more efficiently.

General Notes
  • Full updated documentation for CoinBridge Android SDK V1.0.32 can be found on CoinBridge Knowledge Center.
  • Customer Care or issues reporting– as agreed per SLA
  • Technical issues or clarifications may be done directly via Slack.
Light bulb New Features
| Google Biometric Prompt Requirement (to allow readiness for payment)

In order to increase payment flow security, to allow a user to perform a payment, the mobile application must authenticate the user using the Android operating system Biometric Prompt.

CoinBridge SDK now supports and requires the Android operating system Biometric Prompt to be used.

Before using the PrepareToPay method, it’s now mandatory to utilize the Android Biometric Prompt for user authentication during EMV transactions.

Enhanced User Authentication

If a user attempts to make a payment near an EMV terminal without completing a biometric identification in the last 90 seconds, the SDK will trigger the onCredentialsRequired event in the CBTerminalTapListener interface, and the Tap event will fail.

To avoid such cases, you will have to utilize the Android Biometric Prompt for user authentication before calling the prepareToPay method.

Transaction Failure Prevention
Failing to complete the biometric identification step will result in a tap failure, and the payment token data will not be transmitted to the EMV terminal as should.
Improved Security
The Biometric Identification mechanism serves as a crucial security feature, ensuring the identity of the paying user and mitigating potential security risks during transactions.

Full information about Google Biometric Prompt is available within the CoinbBridge SDK updated documentation.

| “Pay with currently open app” Flag updates

In some Android devices, this flag is enabled by default, while the user cannot configure it. This new version makes sure that in these cases, the corresponding CoinBridge tool will return “True”

Previous Behavior

As part of the Pre-payment journey, before calling prepareToPay, it was necessary to check whether the ‘Pay with currently open’ flag was enabled.

If this flag was not enabled, users were prompted to enable it to allow NFC payments through the application.

On certain devices, this flag didn’t exist, and it was always on (the device default was to allow payments with the currently open app, and there was no option to disable it).

In this case, the utility returned ‘false,’ and users couldn’t make any payment until they enabled this flag.

Updated Behavior

The behavior of the ‘Pay with currently open’ flag has been modified.

Starting now, if this flag doesn’t exist on the device, the utility will automatically return ‘True.’

This change simplifies the user experience, ensuring that payments can proceed seamlessly, even on devices where the flag is not present.

| Payment App Management
On Android’s Contactless settings page, the application’s name and logo are presented. This new version will allow the application to control the name and logo.

With this update, a new SDK feature is introduced to update the ‘Contactless payments’ settings in Android to show your app/brand custom name and banner.

Depending on the device model, the “Contactless Payments” settings screen might show your application name or logo.

You will be able to customize this screen, by selecting a custom banner and a unique description name.

These customization options enhance brand identity and strengthen the relationship with your users.

This provides a more personalized and branded experience for users, promoting your application’s integrity.

Default value – CoinBridge name and logo.

Bug Fixes & Behavior Modifications
| Behavior updates

Security Considerations – We’ve added recommendations for obfuscation of source code (see new section: Security Considerations)

TerminalTapListener – In case “onTapDone” or “onTapError” returns – the device will no longer be ready for payment (the CoinBridge SDK will return the “onPaymentStoppedPay” callback)

TerminalTapListener – “OnTapFinalization” callback was removed. From now on, “onTapDone” should be used to represent successful tap process.

Supporting Additional Error Codes – We’ve added support for “Already in Progress / Started” errors for all of our methods (upon relevancy).

| Bug fixes

EMV data of the device’s default payment method was passed to the EMV Terminal upon tap (prior to successful “PrepareToPay” flow).

While in your application, if the user taps his phone without tapping the ‘Pay’ button (without calling the ‘preapareToPay’ method) the mobile device would automatically start communication with the EMV terminal – while using the device’s default payment method.

Resolution: If a user attempts to make a payment near an EMV terminal without completing a biometric identification in the last 90 seconds, the SDK will trigger the onCredentialsRequired event in the CBTerminalTapListener interface, and the Tap event will fail.

General Fixes related to callbacks for Initialization and Authentication methods (related to CBPaymentStatus)
General Notes
  • Full updated documentation for CoinBridge Android SDK V1.0.31 can be found on CoinBridge Wiki.
  • Customer Care or issues reporting– as agreed per SLA
  • Technical issues or clarifications may be done directly via Slack.