Does Google Wallet / Google Wallet for digital goods API Support 3D-Secure? - android-pay

I am seeing a % of failed transactions with Google Wallet. The error message that I get is
You cancelled this order. Reason: Other. Message sent to the customer: We were unable to process your order..
I have phoned for Wallet support and I've been told that the two examples of failed transactions were down to latency issues.
Whilst I haven't been able to prove it - I suspect that Google Wallet doesn't support 3D-Secure
http://en.wikipedia.org/wiki/3-D_Secure
A google search gives me more questions and doubt but no definitive answer
Does anyone have any experience with this working / not working?
Ben

I had the below email response from Google support, hopefully it will make the situation clearer for others having similar issues.
Please be advised that Google Wallet does not currently support 3-D Security protocol, which is used by Verified by Visa, MasterCard SecureCode and similar services. If your card-issuing bank requires this feature, we suggest using an alternate credit card for your Google Wallet transactions

Google wallet uses direct CVV access , it is successfully carrying its operations at USA because most of the banks are using CVV tech till now, in Asia till now it is only available om discover( Dinner Club Card international Network) and JCB card issued in Japan and China. Google wallet is not supported on verified by visa or by Master-card secure code, if you want to use Google wallet you need to have a valid US address with valid US phone number, if you want the service in japan you first need to access your NFC chip present on your debit/credit card by your mobile then install Google wallet. Till now it is not present on any other Asian country , Yes it is available in Russia but you cant add more than 3000 Rebels into your Google account. Wait till it gets into your country or use similar app provided by bank/developers from your country.

Related

API to change the credit card used by a google wallet subscription?

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....

Not sure which Google Wallet API to use

I'm building an application for a new small business. They run events at race tracks, and the application is a registration system for said events. As a small business the owner doesn't want to worry about handling people's credit card info. They are just starting up and we are building from the ground up. So we are looking at using third party services like Google Wallet and PayPal.
So looking at the documentation, we have the Instant Buy API. Seeing as we aren't planning on taking direct credit card payments, it seems like a pain to setup payment processing through another service to use the Instant Buy. But we aren't selling a "Digital Good", as far as I can tell (I haven't seen a documented definition for this), so does that mean we can't use the API for Digital Goods? I haven't found any documentation that lays this out as a policy. It seems like it would be a lot simpler to implement, even with the cut Google takes.
There is a page at the google wallet documentation site called Which API Should I Use?, the first item there is:
The quick answer: it depends on your goals, your platform and what
kind of goods or services you're selling. The Instant Buy APIs are for
selling physical goods, while digital goods sellers should use the
Google Wallet for Digital Goods API for web apps or Google Play In-app
Billing for Android for native Android apps. To engage your customers
with offers and loyalty programs, use the Wallet Objects API.
Now, the Instant Buy APIs are for those business that have an existing payment gateway setup, but need to offer Google Wallet as a payment option.
In your situation, as you don't have a payment processor setup:
To sell physical goods on web apps and mobile apps that run on
browsers, use Instant Buy for web. You'll keep your existing payment
processor and optimize your payment flow with Google Wallet, just like
with Android. You can use Instant Buy for web to sell digital goods,
but if you lack a payment processor or resources to maintain and
develop a PCI-compliant online store, you should use the Google Wallet
for Digital Goods API.

Use Google wallet with braintree payment gateway

I want to know, can i use google wallet with braintree payment gateway in android application. To be more technical clear, take MASKEDWallet from google wallet and fetch all useful information from it and send it to braintree payment gateway for completing the purchase.
Please help.
I'm a couple of days into working on same, so this is devoid of technical specifics (more conceptual). Also I'm doing so on the "web" side of Wallet Instant Buy (not Android), though the concept of sending payment details through, and meeting (PCI) requirements, to your (any) credit card payment gateway should be the same.
Unless I'm corrected by a Googler:
You'll need to make a FullWalletRequest to obtain the "full wallet" which means the actual card details that you need to send to your gateway (card no, cvc/cvv, expiration, billing address etc.).
At which point, it wouldn't differ from any other/existing (gateway type) credit card processing.
At the end of the day, what Google Wallet Instant Buy does:
provide a merchant application (droid/ios/web) a "Virtual Onetime Card", which,
represents a Google Wallet user's real card stored in his/her Google Wallet account, therefore securing actual card details and scoping the transaction (because it's one-time)
I would think the only possible caveat is whether or not a gateway accepts such type of of card (" a MasterCard-branded virtual prepaid debit card")..unlikely that would be an issue (in US, which is where the API is limited to at this time...)....
Digressing a bit. The other caveat that comes to mind is if you employ some fraud screening service. You're given a "virtual card" (not the real card of a cardholder), so if your service uses/needs that information to come up with a risk score, then its something you need to account for...
Hth....

Linking google merchant account doesn't work even in supported country

I am trying to link my Google Merchant account with my Chrome extension on the dashboard following this guide and even though it suppose to be supported I am getting this message:
The country in which your Google Wallet account (info#wips.com) is registered is not supported at this time.
I am registered from the Czech republic and here it is clear the it suppose to be supported:
https://support.google.com/wallet/business/table/3539140?hl=en&ref_topic=4490611
I have succesfully create my Google Merchant account, so I have the Merchant ID, the seller identifier and the Seller secret.
Can you tell me if I am doing something wrong? Or all the changes that happened yesterday are still taking place?
Thank you very much.
Lukas Jan Marek
Wips.com
It appears that you are planning to sign up as a merchant for Chrome Web Store Payments which uses the Wallet for digital goods API. The merchant eligibility page you point to is for the Google Play In-App Billing API which has a wider country coverage.
The Czech Republic is not yet supported by Chrome Web Store Payments. Here is the current merchant country availability list for the Wallet for digital goods API:
http://developer.chrome.com/webstore/pricing

how does retailer connect to Google wallet acount in a third party website?

I'm a developer of a website that enable retailers to interact with rheir customers at events. the way it works is that the retailer selles a product on my website, the costumer buys it on my website, i'm the common thread. i want to offer the consumers to pay with google wallet. the question is how does the retailer coonect his google wallet business acount to the button which will be on my website? can it be done with the email he has opened his google wallet business acount? Thanks! Amitai.
Unfortunately, the seller doesn't have access to any information about the customer. You need to be able to obtain the JWT or Merchant Key from the original retailer to be able to perform sale on your own website. Only tool you have available to pass information around is the JWT. There are several security and process issues related to this.

Resources