I'm trying to place API calls to charge shoppers in BlueSnap's Sandbox - using a simple Auth-Capture call and I'm not sure which test cards I can use:
<credit-card>
<card-number>4263982640269299</card-number>
<security-code>837</security-code>
<expiration-month>02</expiration-month>
<expiration-year>2018</expiration-year>
</credit-card>
I'm looking for reference on:
1. Can I just use any test card I find on Google?
2. Can I test card failures somehow?
3. Do online wallets work with the same type of cards?
I asked BlueSnap's Support team and this is what they say:
It doesn't matter if you use API or not - also the BlueSnap console (UI) allows using test cards.
Sometimes you can use Google to search for test cards - but if you're testing with BlueSnap, the best option is to use this page for reference.
The provides you with different card brands & currency scenarios and also you can choose specific cards to get the result you want (success or failure).
Be sure to scroll all the way to the bottom and see the Apple Pay test cards - for other wallets you can keep on using the cards at the top table.
Related
I am trying to run payments through PayPal in sandbox mode with my .NET CORE 3 project.
The idea is to give the customer ability to choose whether to pay using his/her PayPal account or Credit Card.
I am using the PayPal-NET-SDK v2.0.0-rc2
I am trying to understand whether this is the right order to run things:
Create Payment using PaymentCreateRequest
At this point, I get the approval_url. I redirect the customer and approve the payment/order using Credit Card
Execute payment using PaymentExecuteRequest, using the PAYID and PAYERID I get from the redirect URL. Here I get an order object
Authorize order using OrderAuthorizeRequest with the order id (setting body to a PayPal.v1.Orders.Capture object)
Capture order using OrderCaptureRequest with the order id (setting body to a
PayPal.v1.Payments.Capture object)
Is that a correct execution order?
Rather than the old v1/payments, you should use v2/orders; the v2 SDK can be downloaded here
Rather than an old-style full page redirect to an approval_url , it's much nicer to use the new checkout's in-context UI that keeps your site loaded in the background. Here is a demo pattern. Another benefit is that it gives an embedded/in-line credit card form.
As a finishing touch once you have everything working, don't neglect to
gracefully handle/propagate funding failures back from your server,
so the buyer can choose something else when declined.
If you start out with intent=capture(v2) or sale(v1), the capture(v2)/execution(v1) call will be final and complete the transaction, there will be no authorize step, so (4) on your list is skipable. (You should only bother with implementing something other than intent=capture/sale if you find you have a specific business need for delaying captures, as it adds complexity)
More general information on implementing the server-side portion of the integration: https://developer.paypal.com/docs/checkout/reference/server-integration/set-up-transaction/
Am using Omnipay with the Paypal and Sagepay gateways. Got it working well, all for except one area - the setItems basket!
I am using the setItems method and adding my name, descriptions and qty for each line item before I send my purchase request.
Works fine with Paypal, however Sagepay does nothing? When I log into Sagepay and view the transaction I just see 'No shopping basket provided'. I assume this does not work for Sagepay then?
Thanks, Dean.
You are correct, there is no support for shopping basket items in the omnipay-sagepay gateway. That's not to say that you couldn't add that support if it's supported by SagePay but there is not any current support for it in Omnipay.
The dev-master branch of https://github.com/thephpleague/omnipay-sagepay now supports the basket (aka items). It supports negative item prices, which appear in the basket as discounts.
Be aware that the costs in the live Sage Pay gateway should add up to the total cost being authorised. I say "should" because the documentation says it must, but the test gateway does not enforce this, so I'm not sure whether the live gateway enforces this either.
I have a few more tests to add, then will make an omnipay-sagepay release with the XML basket support.
I want to perform rigrous testing on Payment Gateway(2checkout) and Pay Pal. For testing, I need to simulate a large number of successful, failed and halted transactions (transaction stopped due to system crash/reboot). But I don't want to make actual payments.
1. Is there any way I can make a test transaction on payment gateway, using fake card numbers or something else.
2. What are the possible advance testing scenarios for Payment Gateway testing?
For example:
Changing the amount, unmask CVV or card from Inspect
element.
List item
There are two options :
Using the PayPal Sandbox (Application Testing), or
Using Dependancy Injection (Unit Testing).
Both would work but I would suggest a Dependancy Injection approach. Assuming you have a separate object that only interacts with PayPal and then other objects that do your actual application logic (and error handling, etc) then you can just create a dummy version of the PayPal interaction object (that always returns true, or conditionally returns false, whatever) and then test your various application classes in detail.
I would suggest you only one solution, look at this Git PayPal-Android SDK and go through the README.md file. Last link tells you how to create a sandbox PayPal account to create dummy transactions across your sandboxed account developer account.
If you have doubts, you can refer Part 1 and Part 2 of AndroidHive tutorial for this.
I have a webshop and im almost there, but I have a number of items for purchase which are downloadable content. I fixed so when a user has paid they are redirected to my pdt.php where they get a receipt, Now I written code for also displaying content if the item-id are == something. Now I wanna make a sandbox/test-purchase of all products that are downloadable ontent which are 28. I can create 28 buttons and have the id 1-28 but that seems stupid. How can I do this easier?
Check out the cart upload command method of sending transaction data to PayPal. It's similar to standard buttons except that you'll include all items in a single form.
Alternatively, if you're familiar with web service API's I'd recommend using the Express Checkout API. This gives you more freedom over your checkout and provides more advanced features as well.
on my website I sell unique items. I have programmed it so that on the selling page, users can select any amount of these items, and it calculates the cost. The key is that I only have 1 of each of these items. So I need the shopping cart system to not allow the payment to go through unless it is available.
I've been searching for a good quick/easy/cheap solution and can't find one. I don't expect this site to make a lot of money (the transactions are a few bucks), so I didn't want to need a ssl certificate.
The only way I know of not needing an ssl certificate would be to use paypal or google checkout. However, I do not think there is a way of using these services and making paypal's server run a script to check how many are available on the site. Any solution?
Thanks
I was thinking about it more, and I think the problem is that once the user gets to the paypal payment screen, I have no control. I guess I could do something like they click the buy it now link, a php script updates it to sold, then they go to the paypal screen, but then they might not continue the purchase...
If you use PayPal Website Payments Standard (using a cart rather than 'Buy Now' Buttons) then you could use IPN or PDT (see the paypal docs here) to get PayPal to call back to you with the status of the payment.
The work flow would then be to set status to reserved when the item is added to the cart, and then wait for the IPN/PDT call to come back with the payment status, and mark the item as sold.
You would still need to check and reset to available any item that had been reserved for longer than say 2 Hours. (You could do this before serving a page to a user so that they have the latest availability and you don't need a cron job or long running process)
If you could provide a little more information about how you have implemented ur shopping card, it would have been more easier for other to assist! If you are using any ecommerce solution then it should be there already in the track inventory section. But Provided that you have implemented d shopping cart manually, why don't you add little bit of codes that checks the inventory status first before letting your customers check out?