I'd like to hide or remove the shipping details or info in PayPal because we provide only services, thus we don't require the Shipping details to show in PayPal checkout page. I am using PayPal RestAPISDK.
Unfortunately the RESTful APIs do not yet have support for the NOSHIPPING variable that is used in the Classic APIs. Address handling is something that is being discussed for future releases.
I was also facing the same problem and sorted it out to some extent.
You just add the following parameter
redirectUrl += "&shipping=0";
and shipping address will not get displayed.
Related
We are running an App with a Angular/Typescript frontend and a .NET backend, using Stripe Elements and Stripe.NET respectively.
We are currently using the "Sources" API.
The frontend can create sources, the backend saves them to our specific users. When you open the frontend again, the backend sends a list of source ids. The frontend then collects the data it needs to display those sources directly from Stripe so the user can pick one of his saved sources to pay and does not have to enter all the data again.
Enter the Payment Method / Payment Intend API.
Due to EU regulations Stripe has a new API that requires us to create cards no longer as "source" but as a "PaymentMethod". So I implemented that in the backend, opened the frontend in my IDE, updated the #types/stripe-v3 package and found the new payment intent API.
The only thing missing: I cannot figure out how the frontend is to access the payment method data, once created. I can create it. Send it to the backend. The backend can retrieve it. Send back the ID to the frontend... and now what? How to display the payment methods available?
I had expected a stripe.retrievePaymentMethod() as there is a stripe.retrieveSource(). But no such luck.
The only option I currently see to present the user with a list of existing payment methods is getting this info on the backend and piping it all, class by class, property by property to the client. Basically copying every single data class stripe has into our own backend REST definition. That cannot be right.
What am I missing? Why is there no stripe.retrievePaymentMethod() on the frontend? Did I not understand some fundamental facts about what those APIs should do?
After contacting Stripe directly, it was confirmed that that's just the way it is:
I think it's just an oversight that we didn't add one.
There are similar functions in the mobile SDK so I don't see why we shouldn't have it
There are no immediate plans to add the functionality back in in the very near future,
so as a workaround, I will tunnel all the data through our backend(s).
If I understand as well, I think your problem is following and the sequence of that. I hope this helps you.
I have implemented a payment gateway like ccAvenue with DotNet and angular, in my case, I send the data to the server, and from the server, I tried to redirect to the payment gateway, but APIs return some result, and the result can not be redirected.
So I created a web-form with implementation, I redirected my app to web-forms page and from there I called the ccAvenue page, and in the response URL, I send the response page of webforms only and after saving the response I redirected to my angular app.
Here is workaround if you want to process 3Dsecure cards and still support other methods like SEPA.
You could attach both, confirmed PaymentIntent (payment method) or Source to the Customer object.
On your frontend you could implement both (StripeElements with client secret for 3Dsecure cards) and IBAN element for SEPA.
I could provide my code example how I save payment intent to the customer. It's in PHP, but for other languages logic should be the same.
Assuming that our client already confirmed PaymentIntent and we have it's id:
$intent = \Stripe\PaymentIntent::retrieve($stripe_intent_id);
$payment_method = \Stripe\PaymentMethod::retrieve($intent->payment_method);
$stripe_customer = Stripe\Customer::create([
'payment_method' => $intent->payment_method,
]);
In case you've already created Customer object before you could use attach method:
$payment_method->attach(['customer' => 'cus_FTkGe4lv5LfyI0']);
Then you'll be able to charge using Customer object PaymentMethod or Source;
I didn't try to attach both methods to the same customer object (we only allow customer to have one payment option at the same time), but it should work. Let me know if it works for you.
I have a problem with PayPal classic API (for .net):
I want to show the details of the object during the express checkout process (PayPal). I used the classic API (.net) and I populated all the parameters (name, details ecc) before call "SetExpressCheckout(passing SetExpressCheckoutReq with element SetExpressCheckoutRequestType -> SetExpressCheckoutRequestDetailsType with details)" of "PayPalAPIInterfaceServiceService".
Usually paypal show me this page (I also set &useraction=commit) KO but I want this! OK
I also try to pass some parameter into query string to paypal (without success)
PAYMENTREQUEST_0_AMT=1.05&PAYMENTREQUEST_0_ITEMAMT=1.05&PAYMENTREQUEST_0_PAYMENTACTION=Sale&L_PAYMENTREQUEST_0_NAME0=Account+PRO+2&L_PAYMENTREQUEST_0_QTY0=1&L_PAYMENTREQUEST_0_AMT0=1.05
Is it possible to set a paypal description page?
Thanks
I'm trying to get the PayPal Express Checkout to consistently only use the "Billing" landing page where card numbers can be entered directly.
I have tried everything I can find on Google, and have ended up with some very odd results. When I redirect to PayPal, I get the "Billing" page 50% of the time, and the "Log in to PayPal / Check Out as Guest" page the other 50% (literally just pressing the back button and then clicking "checkout" again gives different results). I really need to get to the Billing page consistently.
SetExpressCheckoutRequestType pp_Request = new SetExpressCheckoutRequestType();
pp_Request.Version = "117.0";
pp_Request.SetExpressCheckoutRequestDetails = new SetExpressCheckoutRequestDetailsType();
pp_Request.SetExpressCheckoutRequestDetails.SolutionType = SolutionTypeType.SOLE;
pp_Request.SetExpressCheckoutRequestDetails.PaymentAction = PaymentActionCodeType.SALE;
pp_Request.SetExpressCheckoutRequestDetails.LandingPage = LandingPageType.BILLING;
pp_Request.SetExpressCheckoutRequestDetails.FundingSourceDetails = new FundingSourceDetailsType();
pp_Request.SetExpressCheckoutRequestDetails.FundingSourceDetails.UserSelectedFundingSource = UserSelectedFundingSourceType.CREDITCARD;
pp_Request.SetExpressCheckoutRequestDetails.ReturnURL = serverName + returnUrl;
pp_Request.SetExpressCheckoutRequestDetails.CancelURL = serverName + cancelUrl;
pp_Request.SetExpressCheckoutRequestDetails.OrderTotal = new BasicAmountType();
pp_Request.SetExpressCheckoutRequestDetails.OrderTotal.currencyID = CurrencyCodeType.GBP;
pp_Request.SetExpressCheckoutRequestDetails.OrderTotal.value = String.Format("{0:F2}", amount);
pp_Request.SetExpressCheckoutRequestDetails.NoShipping = "1";
As you can see, I'm setting the version AND the Solution Type AND the Payment Action AND the Landing Page AND the Funding Source, and it still doesn't work reliably.
The randomness of it feels like they're doing some A/B testing. Sometimes, on the wrong page, the button says "Check Out as Guest", and sometimes it says "Try PayPal as Guest". Whilst I don't mind A/B testing for text, a complete change of landing page when I've asked it not too seems a bit much.
What else could it be?
First: yes, PayPal continuously tests to improve their flows, so they will be doing A|B testing. The two button texts in particular sound like a classic A|B test, and presumably whatever tests out with the highest conversion rate (which means the most sales for merchants) will be adopted as the 100% solution in the future. PayPal also checks cookies to try to offer the optimal, most-likely-to-convert page to each buyer (e.g. if there is an active PayPal cookie make the PayPal login prominent; no PayPal cookie make the direct card entry more prominent). Again this is done to raise total conversion. You can work to defeat/override these choices but I would not recommend it; by imposing your expectations on your customers you are probably loosing sales.
That aside, some of what you are seeing may not be A|B testing or PayPal's conversion optimization but rather a mismatch between product and usage. ExpressCheckout is inherently a PayPal-branded/PayPal accountholder-centric payment product. It was built with no guest checkout at all, intended to be used alongside direct credit card billing (PayPal's DirectCreditCard API or some other payment gateway/processor). Later on a "guest checkout" was added to Express Checkout so it can be used as a sole solution, but asking Express Checkout to be a gateway is like asking an F150 to be a sportscar (or a sportscar to be an F150). Different product. Yes you can sometimes fit the suitcase in the passenger seat, but if your primary purpose is cargo carrying you are probably going at it the wrong way :).
If your expected usage is hosted but direct card centric with PayPal account holders considered an "add on", then consider PayPal's Hosted Sole Solution. That is PayPal's product that is intended to present card payments centrally but has an "escape" to PayPal accountholder payments rather than the reverse. Or consider integrating through Braintree (which is now PayPal), who has a good SDK that combines Braintree credit card payments plus PayPal accountholder payments.
I'd also throw out there that you might find the PayPal brand isn't so bad for your business. For most small-to-medium merchants it raises trust and can deliver significant sales lift.
Got a response from PayPal Support: it's a bug. That they don't seem to be in a hurry to fix.
UPDATE - PayPal just notified me that this is fixed.
I asked:
"I have a customer who is using Express Checkout and wants the landing page to be the "Enter Card Details" page.
They are a B2B operation, and the presence of a PayPal cookie on the computer of the secretary doing the purchase in no way indicates that a PayPal checkout is appropriate. They're almost always going to want to use a company credit card which is not linked to any PayPal account.
I'm setting all the relevant properties in the request that I can find in your documentation or on google, but they're being ignored.
Is it still possible to force the express checkout to consistently use the Landing Page Billing? "
and they replied:
"The LandingPage variable is being ignored that this point in time by the new checkout flow - this has already been brought to the attention of the developers to get it fixed.
Unfortunately we do not have an ETA for that fix at the moment.
You will be notified once the fix has been rolled out."
I have created a Paypal send payment button from Paypal developers account on my aspx page from which a user can send me payments but i wonder how i can get a unique key, about which user had made me payment.
How can i recognize which person paid me through Paypal.
I can pass any value (his mail id, name, phone number or a unique key) but i don't know how Paypal will return values to me so i can maintain user payment history in DB
is there any good forum on this ?
Please anybody help me.
You can use the CUSTOM parameter for that. It will hold up to 256 characters, so if you need more than one value you can do something like value1|value2|etc and then split it back up on the other end.
When you include the CUSTOM parameter in API requests or standard buttons it will come back in IPN notifications so you can automate processing utilizing that data however you need to.
I am wondering how I specify "Standard Shipping (FedEx Ground or FedEx Home Delivery®)" as a shipping service using the eBay API. Can anyone provide any pointers? All of the samples just use the "Standard Shipping" option.
You need to specify FedExHomeDelivery. A table of shipping services for most eBay sites can be found here. Simply use the values in the ID for importing column for your eBay API calls.
As the types of shipping services change over time you may wish to periodically retrieve the latest services via the API as follows.
For each eBay site that you are interested in make a call to GeteBayDetails with a DetailName value of ShippingServiceDetails.
In the results iterate over all the ShippingServiceDetails elements. Each one is a shipping service for the site that you specified.
Important properties for each service that you will need to check are,
ValidForSellingFlow - If this set to 'true' the service can be used in the Add/Revise/Relist API calls otherwise you can not use it.
Description - You can use this value when presenting services to a user. The text should match what users see when listing via eBay.
ShippingService - This is the value that you want to use in your API calls.
You can find all available shipping methods in the documentation of ShippingServiceCodeType.
Beware to use the correct ones of the site id where item will be placed.