I am new to integrate Google Wallet and there are some confusion and questions related to that given below:
Is it possible to add multiple items for Google wallet?
How to handle discount by API?
What's the parameter in JWT response on postback URL for success and failure transaction?
Is refund functionality available for a transaction by API call?
Anyone have idea about this. Thanks in advance.
Can you clarify which specific API (Instant Buy or Wallet for Digital)?
Is it possible to add multiple items...
Digital - no, you can however "bundle", see this post for clarification.
Instant Buy - it's just a "layer" on top of your (pre) existing purchase/ordering processes and handles (just) the payment data of a Google Wallet user. The "order details" is something you control. See sample of data you send.
Discounts by API
By API - no. You can pass whatever (pre-calculated) value in both APIs.
Success vs. Failure Postback
Digital - Google will only send HTTP Post to your server URL on successful transaction. See #5: "Google sends an HTTP POST message to the postback URL whenever a purchase completes..."
Instant Buy - not relevant. You are processing the transaction, unlike in Digital where Google is. Instant Buy in a nutshell provides your web site, secure access to a Google Wallet user's data. You need to have your own merchant account/processor, be PCI compliant, etc. That said, you will have the success or failure info that you actually have to send to Google - they need to know if you have successfully processed or not (yup, it's the other way around).
Refund by API
By API - Unless a Googler says otherwise, AFAIK, not at this time, for both APIs.
On that note, for Instant Buy, it's actually unclear to me how to "inform Google" when performing a credit or refund. Its still a "private API" (not GA) so I actually haven't seen its "guts". It's understood that since the merchant uses their own processor that a credit/refund is the same procedure, but letting Google "know" about it (days/weeks after the fact) is something I personally have no actual info on..sorry...I can assume some "button" in merchant center for Instant Buy, but that's just a guess....
Hth....
W.r.t InstantBuy Refunds:
The Refund happens on the virtual one time card that is returned by the Google API. The refund on the card can be done by using any backend payment processor. Once the refund is made to the card, it hits the user's backing card.
Related
I'm working with a web application that allows our customers to integrate with Apple Pay on the web. The customers setup their own Apple Pay merchant accounts, a third party handles the actual payment processing, but our servers are responsible for web hosting and obtaining the payment sessions.
Sporadically for some customers, we receive a 400 error when obtaining the payment session, with a message of:
Payment Services Exception merchantId={id} unauthorized to process transactions on behalf of merchantId={id} reason="{id} never authorized mass enablement transactions to occur via {id}"
(Here all the {id} values will be the same).
Despite sounding like a configuration issue with the account, this will only affect some otherwise identical requests. (Same domain, merchant identity, etc.) It affects some customers but not most; when it does affect a customer, somewhere between 10% to 50% of the session requests will fail in this manner. We have several customers never hitting this error even after processing thousands of transactions.
The phrase "mass enablement" doesn't seem to show up in apple's documentation, and the exact phrase "never authorized mass enablement transactions to occur" produces no results at all when searching the web. The closest I can find is this thread on Apple's developer forums but its not an exact match, and has no answers in any case.
Has anyone seen this error and resolved it?
(I'm also pursuing this matter via Apple support; if that eventually proves fruitful I'll update with an answer.)
This happens when a domain has been registered to a merchant using Apple Pay's Mass Enablement API.
The domain (not the merchant ID) will need to be deregistered by whoever claimed the URL before you are able to proceed, although I would expect Apple Pay's support team would also be in a position to remove the registration for you.
https://developer.apple.com/documentation/applepaywebmerchantregistrationapi
I got this error when using my localhost (not registered for Apple Pay) as the front end of the website making a session token request via the back end whose domain had been registered for Apple Pay.
There are few things that needs to be considered here:
Are you using the correct TLS config (the cert and the key) to make the request ?
Are you using the correct merchant validation file send to you while approving mass enablement for the merchant ?
Once you confirm on these 2 things, there's a hole in the documentation provided by apple.
After hitting https://apple-pay-gateway.apple.com/paymentservices/registerMerchant with above proper config and data this requires a param called partnerInternalMerchantIdentifier this is a unique merchant id that you can use on your end.
register merchant
By default, to get a payment session (https://apple-pay-gateway.apple.com/paymentservices/paymentSession) we might send the primary merchant id that we use for merchant registration in above API which is fair as per their docs.
docs
But to make it work we need to send the partnerInternalMerchantIdentifier which we sent in the above API. This acts as a sudo merchant id to get payment sessions.
Get payment session for newly registered domain
Again I am frustrated by the lack of documentation involved in developing using Google Wallet as a payment gateway and I may switch to another service.
My new question is as follows:
Can I programmatically change the payment card utilized by a Google Wallet for digital goods subscription?
If a card utilized in a subscription expires, that is on the user, However, If I do not provide a means of changing the payment card elegantly, that is on me!
Does anyone know how this can be done? Or would I have to create a whole new subscription to produce this effect? This should be a basic feature of any payment gateway so I am assuming that I am missing something.
It should also be noted that creating a new subscription may be problematic without an ability to cancel the previous subscription via the API. Provided that both the old and new cards are still valid, it would attempt to process the payments for both subscriptions!
On a side note, why does it seem that the Google Wallet API is missing so many key features? (annual subscriptions, subscription cancellation, the issue mentioned above, etc...?)
Thanks again everyone!
If Google can't successfully charge, they'll send you a failure postback which you can use to evaluate what to do with the subscription.
It would be best if you don't equate Wallet to a "payment gateway" (or credit card processing service/gateway) because it isn't.
At the end of the day, Wallet basically gives you some "access" to a Wallet User's data. It's up to the Wallet users' to add/remove whatever payment instruments they have in their Google Wallet.
in Wallet for Digital, Google also handles the transaction - the processing part, so you're freed of any PCI compliance, and related payment infrastructure to get stuff going.
Instant Buy, Google will send you a "virtual card" for you to process the transaction using your own/existing credit card processor/gateway. In this case, you do have to be PCI compliant and have existing infrastructure.
In both cases, you don't have access to the actual Wallet users' payment data. Google locks that stuff down.
Hth....
I am growing frustrated with the lack of features and poor documentation of the Google Wallet for digital goods subscription API.
My question is the following:
If Google wallet sends a postback to my URL, and I do not acknowledge the payment (send status 200), does the payment get refunded or not appear on the card statement in the first place?
It seems rather strange that there is no way to programmatically cancel subscriptions. A work around would be to manage subscriptions on my end and only accept the postback payment if their subscription is valid. This would of course be frustrating to a user if they canceled a subscription, yet they still see a charge to their card and then a refund. I would like to avoid that.
Thanks in advance again everyone.
I'm not a Googler so this is subject to being crucified :)
To get an official response, it would be best to contact Google directly - you should see a "HELP -> Contact Us" in your Wallet Merchant Center.
Important: If you specify a postback URL, your server must respond promptly and correctly to the HTTP POST messages that Google sends for each transaction. Otherwise, the transaction will be canceled.
REF: Official documentation on handling postbacks
This somehow/probably relates to the old question in credit card processing of the difference between an AUTHorization and an CHARGE (aka "capture").
An AUTH for x amount would need to be sent for processing. Otherwise, how would Google send you a positive result for the transaction (aka Google would send you a postback after such successful "Auth" transaction for x amount - re: does account have enough funds to cover x)?
So there would be a "pending AUTH" for x value on card holders' account, subject to "capture" (finalizing, turning that AUTH into a CHARGE) at some later time (perhaps after you successfully acknowledge the postback).
What Google does (e.g. "Void" or "never capture") to that pending AUTH if you don't acknowledge (aka "...transaction will be cancelled"), or whether or not the above scenario is actually what occurs in Wallet for Digital Goods, can only be answered by Google. The above is only a personal (mine and mine alone) insight to standard credit card processing...
Hth....
I am implementing Google Wallet API integration with PHP website. Seems there is no way to add multiple recipients during a single transaction. please let me know if there is any way to do this.
Probably needs some clarification from OP so subject to that clarification:
Google Wallet for Digital and/or Instant Buy, yes, there is only one payer (the Google Wallet account/user who will pay)
recipient however seems to be up to you/your app, more so with Instant Buy since control of the transaction/order flow is handed back to you/your web site. Google (Instant Buy) just handles part of the payment flow (not the entire order/transaction process)
Hth
I'm moving my site's payment processing from Google Checkout to Google Wallet (Digital Goods API), but I'm running into an issue involving payment notification. My goal is to only send licenses to customers after orders are charged, but I don't see how this is possible.
Right now I'm sending licenses to users when I receive the postback JWT, but this isn't the behavior that I want, because, according to my tests so far, it takes about 30-60 minutes to actually charge the customer after the purchase (until then, the order is in a CHARGEABLE state). This is a problem because I've frequently had orders be cancelled before they are charged - I obviously don't want to send out licenses when this happens.
So my questions are:
1) Why aren't customers charged immediately? According to the documentation, "Google Wallet for digital goods orders are charged automatically", but there's no explanation of the delay.
2) Is there any way to receive a notification after the customer is charged? The postback and the success callback that are described in the documentation are both no good for this, because they're both triggered when the order enters the CHARGEABLE, rather than CHARGED state.
I'm hoping that there is some system like the Google Checkout Notification XML API, where different notifications are sent out at each stage of the purchase process, but the Google Wallet documentation makes no mention of such a system.
3) On a related note, is there any way for me to get email notifications when orders are complete? Google Checkout did this, but Google Wallet does not seem to offer this option.
3.) I suggest you send yourself an email through the success_handler via javascript. I'd probably use and ajax call like jQuery's .post and pass all the values such as order ID and so on to a php file and send the email from there.
https://developers.google.com/commerce/wallet/digital/docs/jsreference#successhandler
1+2) Here's how I understand it: CHARGEABLE means the credit card has been authorized, and whatever needs to happen between the banks and all that is in progress. CHARGED means google has actually received money from the banks. So the explanation of the delay (I believe) would be the same as if you buy something at the store with your debit card, then look at the account statement and the charge still is in there as "pending". I am under the assumption that you can pretty much rely on the CHARGEABLE state and consider it paid. Whatever happens after that is probably the same risk as when someone used a fraudulent credit card, and the charge gets returned later, or the customer disputes the charge on their statement.
How did your customers cancel the charges? If that happens, could you revoke the license?