I integrated google pay with stripe and configured test environment in google pay and stripe . Now i want to test it , its not accepting stripe test card to my google pay . Is there any specific test card for google pay ? Is it ok to add original card? , Are they going to charge any money in test environment?
We can use our real card for testing, but in Google-Pay's test mode and/or environment no amount will be charged.
(For India there will be a charge of $1, but in few minutes it reversed back into the same account.)
val googlePayLauncher = GooglePayPaymentMethodLauncher(
activity = this,
config = GooglePayPaymentMethodLauncher.Config(
environment = GooglePayEnvironment.Test,
merchantCountryCode = "IN",
merchantName = "merchantName"
),
readyCallback = ::onGooglePayReady,
resultCallback = ::onGooglePayResult
)
GooglePayEnvironment.Test test mode no amount will be charged
Related
Using Stripe/iOS, the user of the app can pay by credit card or by Apple Pay.
I want, from the app (not the server), to request an email receipt when payment is successful.
For Credit Card payment I do the following:
let paymentIntentParams = STPPaymentIntentParams(clientSecret: <paymentIntentClientSecret>)
paymentIntentParams.paymentMethodParams = paymentMethodParams
if let receiptEmail = self.receiptEmail {
paymentIntentParams.receiptEmail = <email address>
}
let paymentHandler = STPPaymentHandler.shared()
paymentHandler.confirmPayment(withParams: paymentIntentParams,
authenticationContext: authenticationContext) {
…
}
However for Apple Pay payment I don’t know which property to set. In the app, I implement the STPApplePayContextDelegate protocol.
Question: For Apple Pay payment, what and where I need to set the email-address for the receipt? Can you please provide a code snippet?
Thanks
After discussion with Stripe support, it seems that using STPApplePayContextDelegate there is no way to set the receiptEmail property in the payment intent.
The best approach is to change the server and set the receiptEmail at
the server
If you still want to make the change at the app, the workaround is to use the REST API to update the payment intent.
Below is the reply from Stripe support:
The STPApplePayContext does not support this directly -- it needs to be set on the payment intent. The iOS flow for card payments is described in [0] and support receiptEmail in the STPPaymentIntentParams [1], but the Apple Pay flow is different. If not set when you create the payment intent, you would then want to make a call to your server to update the payment intent [2] in the payment flow where you call the completion. Alternately, confirm the payment intent server-side after collecting the Apple Pay payment method client-side [3].
[0] https://stripe.com/docs/payments/accept-a-payment?platform=ios&ui=custom#ios-submit-payment
[1] https://stripe.dev/stripe-ios/docs/Classes/STPPaymentIntentParams.html#/c:#M#Stripe#objc(cs)STPPaymentIntentParams(py)receiptEmail
[2] https://stripe.com/docs/api/payment_intents/update#update_payment_intent-receipt_email
[3] https://stripe.com/docs/apple-pay?platform=ios#client-side
Background:
Having obtained a paymentMethodId from the client with Stripe Elements, I am doing this on the server side:
stripe.paymentMethods.attach(..),
stripe.customers.update(...default_payment_method: ...).
stripe.subscriptions.create(..).
When additional action is required by 3DSecure, the subscription object (returned from create or fetched at a later date) includes a pending_setup_intent, which gives the info needed to resolve the intent (and i've got that working ok).
However if we run the subscriptions.create call when there aren't any payment methods on the Stripe Customer, the subscription object doesn't include a pending_setup_intent or anything else to indicate that the subscription doesn't have a way to pay.
Question:
Short of waiting for webhooks is there some way to have reasonably high confidence that the first payment on the subscription is likely to succeed, ie. there is a card, it's going to accept the payment (and yes, the 3DSecure stuff is sorted)?
Notes:
Although I'm not using trials on the subscription, the billing_cycle_anchor is in the future to provide a free period (basically a trial, but not explicitly making use of the stripe trial concept).
I'm using Stripe API version: 2015-03-24 (upgrading is a lower priority than resolving this)
Further clarification:
At the point we make the call to stripe.subscriptions.create(), the code is not aware of whether the paymentMethod was successfully attached and set as the default (I suppose we could check this, but my hope was that Stripe can handle that for us). For example when using the test card 4000000000000002 the payment method is not attached.
The call to stripe.subscriptions.create is of the form:
{
customer: stripeCustomerId,
billing_cycle_anchor: 1606946400,
cancel_at_period_end: undefined,
items: [{plan: "pro_annual"}],
prorate: false,
expand: ["pending_setup_intent", "pending_setup_intent.latest_attempt"]
}
I am trying to charge cards via Python.
However, I cannot get it to work.
according to documentation I can use the test stripe cards
https://stripe.com/docs/testing
However when using one of the test cards, i am getting error
stripe.error.InvalidRequestError: Request req_y3tPpc4nHFd7Pi: No such token: 4242424242424242
Please let me know how I can test. I do not have a stripe account with cards or balances.
stripe.api_key = "sk_test_4eC39HqLyjWDarjtT1zdp7dc"
a = stripe.Charge.create(
amount=2000,
currency="usd",
source="4242424242424242",
description="My First Test Charge (created for API docs)",
)
The correct syntax is [1]:
# `source` is obtained with Stripe.js; see https://stripe.com/docs/payments/accept-a-payment-charges#web-create-token
stripe.Charge.create(
amount=2000,
currency="eur",
source="tok_visa", # <-- The tokenized card information not a CC number
description="My First Test Charge (created for API docs)",
)
You need to tokenize the card information using Stripe.js using createToken(). [2]
All that being said, the recommended integration path is using PaymentIntents and not Tokens and Charges. [3]
Hope that helps!
[1] https://stripe.com/docs/api/charges/create?lang=python
[2] https://stripe.com/docs/js/tokens_sources/create_token?type=cardElement
[3] https://stripe.com/docs/payments/accept-a-payment#web
I have a stripe standalone account that is activated and is accepting live transactions and connected to a platform stripe account. I am giving below the code I am using for accepting live payments.
\Stripe\Stripe::setApiKey("LIVE_PLATFORM_API_KEY");
$strtok = \Stripe\Token::create(
array(
"card" => array(
"number" => $cardnumber,
"exp_month" => $cardexpmonth,
"exp_year" => $cardexpyear,
"cvc" => $creditcardcvv
)
),
array('stripe_account' => "live_account_header")
);
$strtoken = $strtok->id;
$charge = \Stripe\Charge::create(array(
'amount' => $amts,
'currency' => 'usd',
'application_fee' => $appfee,
'source' => $strtoken
), array('stripe_account' => "live_account_header"));
I want to set up a debug mode in my code that will use the stripe test keys to accept test transactions even though both the stripe standalone and platform accounts are activated and in the live mode. I want the stripe calls I should use when I am debugging instead of making live transactions. I mean how should I change the above code and use test keys when I suddenly want to make a test transaction instead of a live one even though both the platform and the stand alone account are activated and live?
Whether a transaction is processed in test mode or live mode depends entirely on which set of API keys you use. If you use your test API keys, the transaction will be processed in test mode. If you use your live API keys, the transaction will be processed in live mode.
So what you need to do is decide which set of keys you're going to use based on some condition that you can trigger.
Basically, you'd need to replace this:
\Stripe\Stripe::setApiKey("LIVE_PLATFORM_API_KEY");
with something like this:
if ($test_condition) {
\Stripe\Stripe::setApiKey("TEST_PLATFORM_API_KEY");
} else {
\Stripe\Stripe::setApiKey("LIVE_PLATFORM_API_KEY");
}
Keep in mind that you also need to use your test publishable key in your frontend code (for creating tokens with Checkout or Elements) -- trying to create a charge in test mode if the token was created with a live key will not work.
In the sample code you provided, you're creating the token from your backend code (via \Stripe\Token::create(...)). This means that your server is directly providing the card data. This is fine when testing, but in live mode, tokens should always be created frontend-side, via Checkout or Elements. Otherwise, you would no longer be eligible for PCI SAQ A and would need to get your solution audited for PCI compliance.
I would like to implement Apple Pay for web. I was getting a little bit confused by the documentations of Sandbox and Production.
I'm using Mac mini (late 2012) with Sierra and iPad mini 3 with IOS 10.
Can you please help me understand what is needed for Sandbox testing? I was following: Apple Pay Sandbox Testing.
Both devices are on the same WIFI, bluetooth is on, handoff is on and AirDrop is on.
I created a sandbox user and logged in with it to icould on both devices.
I added a test credit card to the Wallet app in my iPad
Do I need to configure merchant id, certificate and merchant domain?
I'm using this simple code that I found here. I can't get canMakePayments() to return true. I receive: "ApplePay is possible on this browser, but not currently activated."
window.onload = function() {
if (window.ApplePaySession) {
var merchantIdentifier = 'example.com.store';
var promise = ApplePaySession.canMakePaymentsWithActiveCard(merchantIdentifier);
promise.then(function (canMakePayments) {
if (canMakePayments) {
console.log("Hi, I can do ApplePay");
document.getElementById("applePay").style.display = "block";
}
else {
console.log("ApplePay is possible on this browser, but not currently activated.");
document.getElementById("got_notactive").style.display = "block";
}
});
}
else {
console.log("ApplePay is not available on this browser");
document.getElementById("notgot").style.display = "block";
}
}
I had similar issues with ApplePaySession.canMakePaymentsWithActiveCard(merchantIdentifier) not returning true in the promise.
Using ApplePaySession.canMakePayments() instead did return true when the various conditions you mention for a sandbox user (pairing, iCloud etc.) were met on macOS Safari, and payments could be successfully handled with hand-off to iPhone and Apple Watch.
It would of course be good to determine what the missing thing is that makes ApplePaySession.canMakePaymentsWithActiveCard(merchantIdentifier) seemingly not return true on macOS. It seems to work fine on iOS.
Apple Pay: sandbox vs production:
I also implemented it. So for sandbox you only need:
a sandbox merchant id
a sandbox user -> log in into the testing device with that user (you can create sandbox test user in your apple pay developer account)
you dont need to host the certificate for the sandbox environment
if you are integrating it through some third party payment provider (eg. braintree), you should set up your testing domain there (eg: http://my-sandbox-website.com)
go to the apple pay on the web website and search for test credit cards -> go to your testing device -> Wallet and add one of those credit cards there
Thats it, you're good to go :)