"MismatchSenderId" for Android platform when sending push notifications

[jakac13]

Hello everyone,

We are currently facing an issue with sending push notifications to Android devices. In the push extract, we encounter a "SenderId mismatch" error with a status of "Fail". This issue affects 90% of our Android devices, while the remaining 10% receive notifications successfully.

We have verified that the project_number in our google-services.json matches the SenderId in the Firebase Console. Additionally, we have updated the Service Account JSON file in the Administration panel (Marketing Cloud), but the issue persists.

When conducting tests via the Administration panel (Test Configuration), we receive a Service Status of "Forbidden" and a Failure Type of "MismatchSenderId" within the Push Job section. All sections "turn green" except Send Status which displays a message "Push Not Sent".

Salesforce support answer: "Open a support case, but I can tell you this is easily fixed by reconciling all the pieces of data: The projectId (aka senderId) you've configured in your SDK is NOT from the same project from which you have provided your JSON authorization file to the server. That is the ONLY thing that returns the error you're receiving."

This kind of indicated that the problem might be in the SDK initialization process. I am looking at the Multiple Push SDKs problem. We are only using expo-notification and @allboatsrise/expo-marketingcloudsdk.

Since this is an unofficial Salesforce plugin there is no additional support offered. Did anyone had this problem with their implementation?

Any insights or suggestions to resolve this issue would be greatly appreciated.

[andrejpavlovic]

I can't say I've seen this message before. What version of plugin, expo, and expo-notifications are you using?

Can you copy/paste the plugin config here exactly as you have it in your code (remove any sensitive info).

Mine looks something like this:

      [
        '@allboatsrise/expo-marketingcloudsdk',
        {
          debug: false,
          appId: process.env.SFMC_APP_ID,
          accessToken: process.env.SFMC_ACCESS_TOKEN,
          analyticsEnabled: true,
          applicationControlsBadging: true,
          delayRegistrationUntilContactKeyIsSet: true,
          inboxEnabled: true,
          serverUrl: process.env.SFMC_SERVER_URL,
          iconFile: path.join(__dirname, 'assets', 'notification-icon.png'),
        } as MarketingCloudSdkPluginProps,
      ],

[jakac13]

Hi @andrejpavlovic, thank you for a quick reply. These are the versions:

• “expo”: “~50.0.17",
• “expo-notifications”: “~0.27.7",
• “@allboatsrise/expo-marketingcloudsdk”: “^50.2.1"

Config file:

      [
      '@allboatsrise/expo-marketingcloudsdk',
      {
            appId: envData.marketingcloudsdk.appId,
            accessToken: envData.marketingcloudsdk.accessToken,
            serverUrl: <url>,
            mid: <mid>,
            inboxEnabled: true,
            applicationControlsBadging: true,
            markNotificationReadOnInboxNotificationOpen: true,
            delayRegistrationUntilContactKeyIsSet: true,
      } as MarketingCloudSdkPluginProps,
      ],
      'expo-notifications',

[andrejpavlovic]

Have you tried without setting mid? It says here not to set the mid during initialization. https://salesforce-marketingcloud.github.io/MarketingCloudSDK-Android/trouble-shooting/multiple-push-sdks.html

[andrejpavlovic]

Never mind - I confused mid with senderId. I guess either way, check if that makes some difference.

Another thing to consider is the google-services.json that you are referencing when building contains only a single client - the one you want to use. I'm not sure if expo/firebase know which client to use, so make sure to only have one item in that array.

[jakac13]

Hi @andrejpavlovic, thank you for the help. I do believe we found the problem, we only need someone to confirm it.

We noticed that push/in-app messages were not sent only for contacts which installed the app before 7th of June. The thing is that we changed our whole Firebase project due to some issues. That means that we also have a new senderId and google-services.json. We of course changed everything in the production code (switched google-services.json file) and pushed the update on 7th of June. Sending push notifications to new users (app install after 7th) after 7th has been successful.

Now, I am a little confused about the SDK initialization. Would changing the senderId (with the new google-services.json) require users to reinstall the app for the new senderId to take effect even though they updated the app to latest version? Or should the updated senderId be automatically picked up by the SDK upon app launch without needing a fresh install? Because that is the current pattern. For old users even though they updated the app, "MismatchSenderId" error is shown. For new users everything seems to be okay.

[andrejpavlovic]

Are the old users still using the old token - would it have to be regenerated somehow? Are you calling MarketingCloud.setSystemToken with latest token from expo-notifications?

[andrejpavlovic]

Issue stale, closing.

[jakac13]

@andrejpavlovic I have to confirm that senderId was wrong. After we pushed the update to Google Play we also did some OTA updates which bumped the version number to latest. Users could still have the old build but the OTA update bumped up the version to latest. We were confused why the problem with MismatchSenderId persisted even if the users had the latest version. Problem is that users do not update their apps frequently and do not have auto update enabled for Google Play. After update through Google Play issue was resolved. Sorry for late answer back and thank you for the help.