I am trying to integrate a payment gateway to my ecommerce website. Should I expect an uptime guarantee from payment gateway? Ideally, I think they should have a monitoring system that can alert me if there are any issues with the gateway (I might integrate with two gateways and I can take one down if it has issues), or is too much to expect? What else should I expect from the payment gateways to facilitate any other issues? (the payment gateway I am talking of doesn't seem to have such enablers)
From many of the major payment gateways (Authorize.net, Beanstream, Paypal, etc.), you should expect very good uptime and a monitoring system in place to alert you of issues.
I've worked in ecommerce web development for 5 years. I recall just a couple of of times where Authorize.net went down for a little while. Clients were notified promptly and service restored quickly. When service does goes down, you can bet the big guys customer service lines go crazy (and so does Twitter).
Related
Banks are now offering payments to be made via APIs and no longer needing to use their host-to-host (h2h) file transfer (connect direct or SFTP) integrations to make payments. The key benefit outlined is that it is a simpler way to integrate.
I am not familiar with host-to-host intergration effort but I wanted to understand how is this a benefit on the API method? as I understand for both the connectivity methods h2h or API there is still integration involved. Does this translate to less effort required in terms of integration with APIs and as a result less development resources required?
Host-to-Host and API method shared same principle, which is synchronize information between our ERP and Bank system. The difference is API method usually based on the call that we request to the bank in real-time (e.g. checking balance, request payment transfer, etc.).
While H2H will be based on batch of information sent between our ERP and Bank System within designated time (e.g. every 15 mins, or else). Both will have integration involved, but for API usually will have deeper integration compared to H2H in our past experience.
I am in the process of creating a product where users can use both a mobile app and browser. The APIs are exposed as REST calls. As of now these REST APIs will not be called by any third party.
Should I consider rate limiting API calls?
Short answer, yes. There are libraries out there for doing it. But if the question is just whether or not it should be done, then IMHO yes.
I have done this for personal projects and for previous employer, its not that hard. Just yesterday a friend told me how he inadvertently brought down a 3rd party service his employer was using. He made his company's services faster which lead to more requests to the 3rd party service and brought it down. So his web services were rate limiting the 3rd party service by being slow. If the 3rd party service had rate limiting this would have been avoided.
Rate limiting is important to protect downstream resources, like DB's. If you do not protect these resources you might run into an unrecoverable outage due to a spike in traffic.
Its important that you prioritize the development and deployment of this compared to the other things your new product will require... e.g. might not be needed for versions 0.x.
I just wanted to ask among the gurus here if anyone has ever attempted to test a complete transaction from start to end on an ecommerce site using paypal or any other epayment gateway.
Please guys, I would appreciate any thoughts and comments. As it is a live site, I cant use the sandbox as that will negatively impact sales. However my firm is a startup and so can't afford the complete transaction and refund process that was suggested [here]:Accepting dummy credit cards on a live site with ActiveMerchant & PayPal.
Please help!
Previously I tested by buying low cost items from myself - that way you're only paying commission and you're getting most of the moneyback.
Admittedly you need 2 Paypal accounts, but that shouldn't be a problem, and you should only have to 'kick the tyres' in the live environment because all your testing will have been done in the dev environment.
We had a similar problem during startup and still use this process in the live site. We have specific "test" products that we purchase using a live credit card, then monitor the transactions: purchase, decline purchase, subscription (recurring billing), cancel, refund, etc.
Our test product is priced very low (5 cents). For subscriptions, the billing interval is 1 day, for a maximum of 3 intervals (with a free trial period of 1 day). This allows me to run a full test/validation, including recurring billing, in the live environment in less than a week.
We refund all charges following the test, which puts the money back on the credit card (or back in the PayPal account). Because of the refunding, our sales impact is zero (offsetting sale and refund). It does cost us a small non-refundable PayPal fee for each transaction, but that amounts to $1 or less.
These "test" products are not exposed to normal users. Also, we manually verify any "test" sales to make sure they are part of our internal testing.
"Sandbox" testing is the way to go during development, but a periodic test in the live environment is necessary to be verify that nothing is amiss.
Why not use a real credit card, then give yourself a refund? The commision fee is returned in that case.
All the time that I want to test our live sites we use a real credit card.
Thanks
I don't understand why you can't use the sandbox..?? How would using it negatively impact your sales? It's all fake.
Just setup your own sandbox.yourdomain.com version of your site and use that as your test server. Configure it to use PayPal's sandbox with sandbox API credentials, etc. This will allow you to go all the way through an order process and test everything from the UI stuff to payment processing, API requests/response processing, IPN, etc.
When everything is working you sync it up with your live server, which is hitting the live PayPal server, of course.
Again, I don't see how that would impact you in any way other than being a successful testing solution..??
I'm looking for a stockbroker but can't seem to find one that 'ticks all the right boxes' - can anyone help please?!
The essential requirements are:
Supports Shares ISA accounts
Access to ETFs on the LSE, especially iShares
Real-time price info/trading (with as low latency as possible)
Low fees/charges (preferably with a heavy discount for say 10+ trades per week)
Available to individuals, not just institutions
Execution-only is fine, don't need anything fancy. The ISA requirement probably restricts it to UK brokers I guess. There are loads of brokers that do all of the above, so then it comes down to my key additional requirement:
API access, e.g. FIX (for automated/algorithmic trading)
But I can't find any brokers that have both ISA support and API access. I guess it mustn't be a common requirement for individual investors in the UK but it seems commonly available from US brokers. I can probably live without API access if I really have to. (As long as there's a web interface, which they all seem to do nowadays. And I have no requirement for desktop/mobile trading platform software.)
My 'would really like but can be flexible on' requirements are:
Existing (open source/cheap) connector for Marketcetera or similar
Real-time level 2 price info at a reasonable price
DMA (Direct Market Access) on the LSE at a reasonable price (preferably without a massive 'professional client' process to have to go through)
Then the optional/'nice to have's are:
Demo/'monopoly money' account for testing
Ultra low latency pricing/trades
Can switch into CFDs/spreadbetting
Also supports SIPPs
So, does anyone know of any brokers that meet some/all these requirements?
The cheapest ones I've found that meet my essential requirements are x-o.co.uk and hl.co.uk, both currently charging £5.95. There's also share.com whose Premium account might be useful in the future but rather pricey up front - £3000 per year for unlimited trades with no other major charges. E*TRADE might have done the job but they're no longer trading in the UK. Interactive Brokers seems to be the only choice for API access in the UK (?) but they don't support ISAs. (They've said "After reviewing this we have decided not to support ISA's at this time." so it won't happen anytime soon.) There are some nice-looking platforms like Marketcetera/JBookTrader/tradelink/ActiveQuant - but if they can't connect to a broker that does ISAs they're skuppered for my purposes.
And some additional questions while I'm thinking:
Anyone know how much latency there actually is on a normal UK retail broker's web interface's "real-time" prices/trades?
Are stock prices pretty much the same across different brokers? I read in a review somewhere that one broker didn't offer as good a stock prices as others?! Is this down to the RSPs they use maybe?
Is it even possible to get DMA on the LSE at a reasonable price without a massive 'professional client' process to have to go through?
It seems that IG brokers may have both ISAs and and an API... Can't seem to find any others.
I've written a subscription based web app that I want to charge (by credit card) a monthly fee. There are 3 different plans and once they sign up, they should be billed that amount, automatically, every month until they cancel. Is there an easy way to set this up (some sort of online service maybe?).
You can use Paypal's merchant service to provide reoccurring charges for a subscription.
Pretty easy to implement, they provide plenty of examples and even a sandbox to get you up and running.
There are now some service providers that take care of your billing and subscription needs. You use their API and they handle billing and subscriptions for you. Their services work with payment systems like PayPal and Authorize.Net.
Take a look at the following sites:
Chargify
Spreedly
Cheddargetter
I would suggest not using Paypal or Authorize's recurring payments directly. Their APIs are brutal, and the functionality is very rudimentary. It may work fine for when you're just starting out, but if you ever want to change anything down the line, you'll be in trouble.
I work for CheddarGetter, so I'm biased, but you should check us out.
Our competitors are not as robust or flexible, but they are definitely better than using Paypal or Authorize.net directly.