Duplicate class com.squareup.Pan in reader-sdk and in-app-payments-sdk

Questions
,
1

We got “Duplicate class com.squareup.Pan found in modules jetified-card-42.jar (com.squareup.android:card:42) and jetified-reader-sdk-internals-1.5.1.jar (com.squareup.sdk.reader:reader-sdk-internals:1.5.1)” error when building our Android project which supports Square in-app purchase and payment by Square reader.

We can get through this error by adding exclude statement:

    implementation("com.squareup.sdk.in-app-payments:card-entry:1.5.0") {
        exclude group : 'com.squareup.android',module:'card'
    }

However it will crash when taking payment with in-app purchase.

java.lang.NoClassDefFoundError: Failed resolution of: Lcom/squareup/Card$Brand;
        at sqip.internal.CardEditorState.<init>(CardEditorState.kt:23)
        at sqip.internal.BaseCardEntryActivity.onCreate(BaseCardEntryActivity.kt:119)
        at sqip.internal.CardEntryActivity.onCreate(CardEntryActivity.kt:38)
        at android.app.Activity.performCreate(Activity.java:8183)
        at android.app.Activity.performCreate(Activity.java:8167)

Please help resolve this issue.

2

Hi there @groomore, welcome to the forums! :wave:

The In-App Payments SDK and Reader SDK are intended to be alternative solutions for payment processing in iOS/Android apps (with In-App Payments being designed for customer facing apps, and Reader SDK being designed for in-person seller facing apps). Because of this, they will not work within the same app.

3

Hi, thanks for the reply.

One user may not use both in-app payments and in-person payments (with reader SDK) indeed.

But as a SAAS developer, we need to provide two possible ways to users and let them choose which method to take payment.

Is there any workaround we can take?

4

Currently the only workaround would be developing two separate apps for your different needs. I totally understand that this isn’t ideal for your use case, and I’ll be sure to communicate this to the team as something our developers are looking for better support with.

5

Thanks for the advice. We will consider removing in-app payment support in this case.

6

Hey, not sure if you’re still having issues, gave up, or found a solution, but we just spent the weekend solving this problem. It’s posted over in their in-app-payments-android-quickstart repo, in an open issue (link here). High level, the solution is adding the Square-Reader-Sdk repository directly into your repo, and modifiying the “reader-sdk-internals-x.x.x.jar” to not include the “Pan.class” file.

As stated in that ticket, we’re in the early stages of development, and can’t confirm if anything isn’t working outside of the Card Entry module/screen. We’ll be starting development on the actual reader within the next 2 weeks, so we’ll have a better understanding.

We came to this solution because the Pan.class is critical to the Card module in the In-App-Payments SDK, while the Square-Reader-Internal bundles it and imports it separately. Plus, it was easier to access the class than an entire module.

Hopefully, @josh-square and the Square team can take notice to this solution, escalate it and make it so that we can use both SDKs at the same time. If not, I hope, that in future releases they don’t block this solution, otherwise we’ll be stuck at 1.7.1 for the Square-Reader-SDK

Thanks!

7

Hi @eate_dev! Would you mind sharing your use case? We’re particularly interested in understanding why you need both SDKs in one app. These SDKs are built to serve two very different needs. With Reader SDK it a seller facing SDK and In-App Payments SDK is buyer facing. Is there something missing in one which is why you need the other? :slightly_smiling_face:

8

@Bryan-Square You actually answered your question with your question. We have one app that serves both the purposes you mentioned. We cater to both buyers and sellers, and need to do so without having 2 different apps for each of those SDKs. For more details about our product, here’s our website https://www.eatedigital.com.

Is there chance that this will be looked into so that others won’t have to do what I recommended? Myself and the original poster are, most likely, not the only ones needing a Square supported solution, while not being locked into a older, or specific, version that works with my provided solution.

9

We’re constantly working to improve our features based on feedback like this, so I’ll be sure to share your request to the API product team. :slightly_smiling_face:

10

Hello, I encountered the same problem. Is there any new progress? As a SaaS service, we also provide users with in-app payment and reader payment.

11

You can allow for manual card entry with Reader SDK since having In-App Payments and Reader SDK in the same app isn’t currently available. :slightly_smiling_face:

12

Hi Bryan. Reader SDK doc says the authorization requests will only work for US-based accounts. Reader SDK Overview

Is the reader SDK restricted to the US right now?

And, we as a SAAS business let the customer decide if they want to use the Magstripe Reader or use the In-App payments. We also support businesses outside the US where only In-App Payments are supported from Square. Since we couldn’t use the In-App payments and the Reader SDK together, we could not support Magstripe reader for US-based accounts

13

At this time Reader SDK is only available in the US. We are looking to expand on this however we don’t have a public timeline. :slightly_smiling_face: