Apple Pay web sdk with auth + deferred capture with different amount

Do you have a link to your checkout page so I can take a look? :slightly_smiling_face:

Hi @Bryan-Square
Here is the link to try> Please reply ASAP
https://parkbetter.parking.com/g/5TGW91JGFR#/checkedin

Brian - to me it seems like you have it picking up the “Business Name” from “About my business” under “Business information”. You mentioned it should be picking up the “Location Business Name” under “Location Details” under “Locations”.

This is limiting our ability to roll this out, your kind help is appreciated.

The team is working on a fix to pull in the correct business name. I’ll be sure to update this post when its deployed. :slightly_smiling_face:

@Bryan-Square How can I upload same Apple Payment Processing certificate to support Apple Pay in iOS app(CANADA & US) using two or more Square accounts. As per my understanding there can only be ONE active Apple Pay Payment Processing certificate associated with an Apple Merchant ID at any given time.

I tried to upload the already existing US Square account Apple Payment Processing Certificate in to the new CANADA Square account. Here it ended with below error.

Could you please let me know how can we upload a single Apple Payment Processing Certificate into two different square accounts?

It’s not possible to upload the same Apple Payment Processing certificate to two different Square accounts. Each Apple Pay Payment Processing certificate is tied to a specific Apple Merchant ID, and there can only be one active certificate associated with an Apple Merchant ID at any given time.

If you’re managing two Square accounts for different regions (US and Canada), you’ll need to generate separate Apple Payment Processing certificates for each account. Each certificate will be associated with the respective Apple Merchant ID for the specific region.

Ensure that you generate the certificates separately for the US and Canada Square accounts, following Apple’s guidelines for each region. Once you have the distinct certificates, you can upload them to the corresponding Square accounts to enable Apple Pay support for each region. :slightly_smiling_face:

In my case, I have the same Apple Merchant ID for both regions(US and CANADA). So I expect I should not create a another Apple Pay Payment Processing certificate. Could you please let me know if the Square support CANADA & US currency in a Single Square account??

Right now a Square account can only charge in the currency of the country it was setup in. If you have a US account connected to a US bank account you can only charge in USD. Same with a Canadian account connected to a Canadian bank. You’ll only be able to charge in CAD.

You’ll be able to accept internationally issued card however the currency you can charge in is the currency of the Square account. :slightly_smiling_face:

@Bryan-Square
We have integrated the Google Pay in Android using In-App Payments SDK. It is working fine in Sandbox. When we tried by switching to Production environment. We are ending up with the error attached below

We have gone through your checklist for production. We see a instruction stating that,

  1. Complete a Google Pay API Production Access Enablement Request Form:
  • The Tokenization Method must be gateway.
  • The Payment Processor or Gateway form field must contain square.

==> Should we have to complete the form mentioned above to integrate Google Pay in Native Android?

NOTE: We already integrated Google Pay in web in PRODUCTION ENVIRONMENT.

Yes, that is one of the requirements for processing Google Pay payments in production. :slightly_smiling_face:

@Bryan-Square Can you elaborate how Google Pay web payments working in production with out any form submission. And also how web vs native google pay differs?

@Bryan-Square Could you please let us know what is the cost/fee structure for pre-authorization and charge in square? Please reply ASAP.

Currently, we only take a fee when a payment is made and goes to a completed state. If a payment is authorized and eventually voids we won’t take a fee from the payment. For more please see our Payments pricing page. :slightly_smiling_face:

Hi @Bryan-Square

Thank you for your quick reply. Can you please reply for below questions.

  1. Once a transaction is authorized, how long can that be on hold before we void it?

  2. Is there an additional fee if we authorize for an X amount and charge higher or lower than that?

  3. If we have authorized an user, can we re-authorize or tokenize once again while still holding the first one?

  4. The current scenario we have at hand is deferred charge, We authorize a user before and charge later. Do you see if this Use case is the same as Pre-Auth for all the transactions?

  5. After the time period expires, if the payment is not in a terminal state (COMPLETED, CANCELED, or FAILED), Square cancels the payment. Do you charge any fine/penalty for square cancellation?
    NOTE: Above questions are with respective to Square Apple Pay & Google Pay
    Please reply ASAP.

Yeah, of course:

  1. Once a transaction is authorized by an API payment, it can be held for up to 7 days before it’s voided.

  2. There is no additional fee if you authorize for a certain amount and then charge a higher or lower amount. However, the fee collected from Square is based on the final amount charged.

  3. If you have already authorized a user, you can re-authorize or tokenize the a new transaction while still holding the first authorization. However, please note that each authorization will place a hold on the customer’s funds, so it’s important to manage authorizations carefully.

  4. The deferred charge scenario you described is similar to a pre-authorization, as you are authorizing the payment before actually charging the customer.

  5. After the authorization period expires, if the payment is not completed, canceled, or failed, Square will automatically cancel the payment. There is no fine or penalty for this cancellation.
    :slightly_smiling_face:

Hi @Bryan-Square

We are using Square Apple Pay Pre Auth. Whenever we set autocomplete to false for an Apple Pay transaction, the APPLE WALLET “transaction history” immediately shows the amount we are pre-authorizing. However, when we complete the payment, the APPLE WALLET “transaction history” does not reflect what we actually charge the user immediately. This is causing customers to think they are double-charged.

NOTE: We are seeing the actual charge transaction in the APPLE WALLET history approximately after 24 hrs.

  1. Please provide your insights on how to address this transaction history issue and how we can let user know its a Pre-Auth transaction?

  2. We are seeing our Business name as Square3 in wallet history. Could you please point us where we can update it in the portal to our actual Business name?

Adding screenshot for reference of usecase where Pre-Auth amount is $6.01 which reflects immediately and actual charge was $3.01 which do not reflect immediately.

Please reply ASAP.

In all honesty you’ll need to reach out to Apple to discuss the way that they display the transactions in the Apple Wallet. We are sending all the information to display to the customer but it’s there UI that they control and have access to change.

As for the display name it’s getting Square3 from the business name that’s configured for the account. If you want to change that you’ll need to update the Business name in the Square Dashboard. :slightly_smiling_face:

Hi @Bryan-Square ,
We have separate application IDs for our US and Canada locations (2 Application IDs) and need to access the respective ID based on the garage location.

<meta-data
            android:name="sqip.SQUARE_APPLICATION_ID"
            android:value="@string/GOOGLE_PAY_APPLICATION_ID"/>
  1. How can we dynamically set the application ID in the <meta-data> tag of AndroidManifest.xml based on the specific location, considering that the manifest can only hold one ID at a time and cannot have duplicate names?

Please reply ASAP!

What Square product are you using? If this is with Reader SDK this isn’t possible because the framework needs to be installed. Also Reader SDK isn’t available in Canada. :slightly_smiling_face:

hi @Bryan-Square
We are using In-App Payments SDK on Android to support Google Pay.