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....
Related
I've making a SaaS that allows customers to subscribe to a plan, and use coupons at the checkout stage. The coupons give the customers X% off for X months, and by default, everyone gets a 7 day trial when they subscribe.
What is confusing me is the documentation. In one section it says that you should create SetupIntents to take a payment and elsewhere it says to use tokens.
I'm in the middle of coding the payment flow, but I just wanted to check to see if my logic and understanding is correct. Could anyone validate the below?
Customer enters card number and coupon
Call Stripe, get token for card
Send token and coupon to server
Create Stripe customer with token
Create Subscription with discount and pass customer ID
What has now happened is an authorisation attempt was made. If SCA is required, then the subscription status is incomplete and the latest invoice payment intent status requires action.
At this point, I can redirect my user to the SCA Flow using handleCardPayment() to prompt 3DS, and once complete the subscription status is then active.
If the invoice payment fails for any reason, then the subscription state is incomplete and the payment intent requires has a payment action required status. At this point, I should present my customer with the React Elements form again, and call the stripe.invoices.pay endpoint with the new card token
Going forwards, all subscription charges should not need further SCA approval, however if the customer changes plan or the bank requests it, then I can point my user back through the SCA Flow process
A diagram of the flow is here: Green is UI, Orange is Server, Blue is Stripe
Is there anything I have missed or misunderstood here? I've been reading about creating SetupIntents and PaymentIntents, but I'm not sure I need this?
If you are creating subscriptions using the Stripe Billing product they handle creating the PaymentIntent(if you are taking a payment immediately) or a SetupIntent (if you are setting up a trial or metered billing). All that you really have to do different is handleCardPayment (for payments) or handleCardSetup (for setting up trials and metered billing). This section in the docs is pretty good.
If you are not using billing they have a video on their Stripe Developers Youtube channel which may help clear up any confusion.
Hope this helps :)
Welcome fellow sufferer, cards and tokens are implemented in Stripe Charges API which is not SCA compilant. If you want use Stripe for payments inside the EU you should use payment intents.
Card tokens are also allowed for creating payment intents.
But if you want reduce the number of necessary authentications you should use setup intents (with usage = "off-session") for creating payment methods and not card tokens.
I have a lot of old customers who have still registered with the Charges API. I use the following strategy:
New customers always register via Setup Intents and Payment Methods.
Old customers use the Charges API until their tokens become invalid. Then they must also use setup intents and payment methods.
Of course, the customers do not notice much of it.
In summary, I would always use payment methods and setup intents for new customers and card updates. Only with the setup intents can you ensure that your customers have to authenticate themselves as rarely as possible.
EDIT: The crucial point is off-session payments that occur with subscriptions. The Stripe procedure is described here: https://stripe.com/docs/payments/cards/saving-cards#saving-card-without-payment
I have a subscription service for which free trials are allowed before signing up for the full payed service. I want to ask the customer to provide credit card details before gaining access to the free trial, to prevent abuse of the trial.
I'm using Stripe to handle payments so that I don't have to deal with storage of any sensitive payment information. This free trial scenario would seem to be very common, so I assumed there would be some way to query a card to make sure that it hasn't been used to sign up already. Just some API call that would accept the card number etc. and return a boolean.
I haven't seen anything like in the API docs. I know that fingerprints of cards are accessible after creating a card source, so is it advisable to store them myself and query them? Or have I missed something in the docs?
Just to be clear... I'm not looking to search a card for a particular customer. I know I can iterate over the cards to do that, but I'd have to iterate over the cards of every customer to accomplish what I want, which is not feasible.
Here you probaly want to contact the support team and suggest this as a new feature.
A possibility is the fingerprint you mention, in my opinion this would be the way i would do it too.
One single card should never be associated with one customer in a platform.
No, there is no way to check whether a credit card is used for another customer or not. And there shouldn't be. Because a customer has right to use his/her single credit card to maintain more than accounts.
You can easily integrate trial feature of a Subscription in Stripe which is best way to implement Trial feature using Stripe. If any customer's payment failed after trial expired then you will be notified by Stripe.
And Stripe and any other payment gateway is not advise to store any card info due to security issue.
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 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....
This is the scenario I expect the system behave:
I have a platform where users can register and store their credit card information online, and with specific user's action, system automatically settles payment.
Of course, user expect automatic payment system as we said so when they enter their card information, and the purpose of this is to simplify the process when they decided to pay for something.
My question is this:
I found that Amazon saves user's card information when they purchased some products then user doesn't need to put all the card information again but just select from the list of cards he used and with one click, it finishes payment.
Also, in price line, I found that it automatically settles after bid accepted.
So I tried to find the provider or payment gateway company that Priceline or Amazon provide, and tried to find the way to implement the system at least, but couldn't find any. What I have found so far were like, using paypal, and it requires user to have paypal id
I'm doing this in PHP, can anybody give me some clue please?
Thanks in advance.
You should be able to do this with most payment gateways that support recurring payments.
Typically what you would do for new customers is capture their card details 'as normal' (via the payment gateway). The payment gateway will return a token id which you then store against the customer record
Next time that customer makes a payment you can submit the tokenised card number to the payment gateway
Since you mentioned Amazon, you might want to look at their payment service API: http://aws.amazon.com/fps/