I am trying to prototype a system that will display a list of choices to a user, and allow them to place an order for the one they select (an over simplification of the prototype, but sufficient to get to the point). I have the users credit card number, billing and shipping addresses, and other contact information, but I can't find any web services that will let me actually purchase something with this information to complete the prototype. I have checked directories such as Programmable Web and Xmethods, but they just seem to point to APIs that let you check for prices and availability, but not actually place an order. Does such a thing exist, or is there some reason (such as security) that I am missing, that prevents such a service from being offered?
The most important thing about online shopping is the security of transmitted information (e.g. credit card data). So the ideal case is to transmit these information directly to the related bank's (issuer of the credit card) payment services, rather than passing it via other service providers. This is what 3-D Secure does.
So when you use a common API this means putting an extra broker between, and passing the secure information to this party which increases vulnerability. Since such a broker cannot use 3-D secure (since it is not the merchant so not possible to make an agreement with the banks) and it should pass the information to online shopping site.
Moreover, an online shoping site can block traffic coming from such an intermediary webservice at any time if you do not make an obligatory agreement and making agreements for each online merchant is practically not very possible.
There is no such free API available the simple reason behind that information like credit card is very secure and confidential and there will security threat on free API's.
here is list of best 10 online payment system
http://sixrevisions.com/tools/online-payment-systems/
and this one who providing live demo
http://www.fastcharge.com/
I think it is possible though I don't know in depth information. I think this is what you see. In next steps you will be redirected to payment gateway of the bank and then you can complete the transactions just by answering some security questions. I think this is a service you should obtain from the bank. And I haven't seen any universal API that can perform the task you have mentioned.
Dialog GSM - Sri Lanka
Anything.lk - Sri Lanka
Related
Our current setup.
We fully outsource our card processing service to a PCI compliant vendor. The way customers enter their card information is from a web page iframe delivered directly to their browser from the 3rd party vendor.
Our understanding this gives us the green light to use Checklist A because we do not control the page and card data never touches our company network.
My question:
We also have a billing application (on our network) that also has an embedded browser to which a credit card entry page is loaded from the 3rd party (iframe). We use this in case a customer calls us to update their card info.
Our accounting department types the updated card number into the web page (delivered from the 3rd party) and posts the update.
Does this process now exclude us from using checklist A?
Many thanks for responses.
Regards,
Bryan
When your agents key in a customers details they are classified as using a Virtual Terminal:
A virtual payment terminal is web-browser-based access to an acquirer,
processor or third party service provider website to authorize payment
card transactions, where the merchant manually enters payment card
data via a securely connected web browser.
SAQ A is likely not applicable, there is a specialised SAQ that covers this: SAQ C-VT which is for:
Merchants with Web-Based Virtual Payment Terminals—No Electronic
Cardholder Data Storage
This is something you should ask your service provider or a QSA to clarify/help with.
I'd be careful about using SAQ-A as it only applies if:
Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;
And, you most certainly can't use SAQ-C-VT as it only applies if:
Your company’s only payment processing is via a virtual payment terminal accessed by an Internet connected web browser;
Consequently, if I were in your shoes, I'd be using SAQ-C. SAQ-C sucks though, so if I were in your shoes, I'd be even more tempted to implement a user login/credit card update form so that customers can update their own credit card numbers, keep your accountants entirely out of the loop, and let you stay at an SAQ-A!!
I have a .Net application that uses list of names/email addresses and finds there match on Facebook using the graph API. During testing, my list had 900 names...I was checking facebook matches for each name in in a loop...The process completed...After that when I opened my Facebook page...it gave me message that my account has been suspended due to suspicious activities?
What am I doing wrong here? Doesn't facebook allow to search large number requests to their server? And 900 doesn't seem to be a big number either..
per the platform policies: https://developers.facebook.com/policy/ this may be the a suspected breach of their "Principals" section.
See Policies I.5
If you exceed, or plan to exceed, any of the following thresholds
please contact us by creating confidential bug report with the
"threshold policy" tag as you may be subject to additional terms: (>5M
MAU) or (>100M API calls per day) or (>50M impressions per day).
Also IV.5
Facebook messaging (i.e., email sent to an #facebook.com address) is
designed for communication between users, and not a channel for
applications to communicate directly with users.
Then the biggie, V. Enforcement. No surprise, it's both automated and also monitored by humans. So maybe seeing 900+ requests coming from your app.
What I'd recommend doing:
Storing what you can client side (in a cache or data store) so you make fewer calls to the API.
Put logging on your API calls so you, the developer, can see exactly what is happening. You might be surprise at what you find there.
I'm looking for a United States Address Validation web service, as the title says. Also:
I don't need maps
I don't need Geo coding
I do need:
Validation that an address is real
Address parsing
Google's Maps / Bing Maps seemed good, but won't work for me because of these:
Prohibits use if not plotting points on a map image
Low request limits (100,000 / day) for premium account. I need more like 1,000,000 / day
Does Geocoding, which I don't need, which is resource intensive, which means it's slow
Any suggestions?
Maybe USPS?
https://www.usps.com/business/address-management-products.htm
use FedEx's API. They have an API to validate addresses.
Also:
https://webgis.usc.edu/Services/AddressValidation/Default.aspx
You can try Pitney Bowes “IdentifyAddress” Api available at - https://identify.pitneybowes.com/
The service analyses and compares the input addresses against the known address databases around the world to output a standardized detail. It corrects addresses, adds missing postal information and formats it using the format preferred by the applicable postal authority. I also uses additional address databases so it can provide enhanced detail, including address quality, type of address, transliteration (such as from Chinese Kanji to Latin characters) and whether an address is validated to the premise/house number, street, or city level of reference information.
You will find a lot of samples and sdk available on the site and i found it extremely easy to integrate.
You could, in theory, run desktop software and plug into any kind of API it provides, but then you become responsible for things like uptime, data updates, and associated overhead. You may also run into issues with the software threading model--is it multi-threaded or single-threaded software? You don't want to find that out in production.
There are a handful of web services out there that can verify US-based addresses, including the USPS official web service. The USPS one is very limited in the fields that it returns. For example, if you're looking for the "delivery point" which is used to make a full barcode, the USPS API doesn't return that information. I believe the USPS web service also limits the number of queries that you can perform, although I don't remember the exact limit.
A few things that you'll want to look for in a web service include the price (obviously) as well as geo-distribution of their servers. If a company has all of their servers in one location and that data center goes offline (which can and does happen), you're left out in the cold. If they have multiple physical locations, it can help to prevent unnecessary outages. Also, you'll want to make sure that the service call returns all necessary fields as per your requirements--like delivery point code, barcode, and DPV code (which tells you how deliverable an address is).
Lastly, you'll want to determine how you feel about interacting with the company. When you call them on the phone, are they responsive and concerned about your needs? Or are you talking to some front-line person that can't answer questions and is only able to gather information about your company size and revenue so they can evaluate how big of a fish you are and determine which salesman gets to call you back. Can you talk to the engineers that wrote the web service on the phone or via email?
There are a few choices out there and you'll have to choose the one that best fits your requirements and unique situation. Do a Google search to find a list of companies. In the interest of full disclosure, I'm the co-founder of SmartyStreets. We have an address verification web service API called LiveAddress. You're more than welcome to contact me directly with questions on my personal Twitter account or the company Twitter account.
What options exist to facilitate payments to banks or credit card companies? Are there programmatic APIs for banks that, say, perform the same actions as paypal might? I'm looking for libraries or options that aren't through an existing provider; that could be developed on their own.
Basically, lately I've become interested in ecommerce and I'm wondering how the communication between a website and a bank or credit card company is made.
I've looked around a bit, but I'm not really sure about the terminology in the field; any resources you could point me at, or good books about the subject would be awesome. Thanks!
You get a merchant account with a bank, then sign up with a merchant processor like Cybersource or Litle. The merchant processor provides an webservice API to process authorizations, payments, credits, and voids. You implement the processor's API and then you can do online payments. They act as a go-between for you and the credit card company. You're not likely going to get permission to communicate directly with the credit card's network.
Maybe use this link as a starting point. This is cybersource's API documentation.
I've been tasked with setting up a society's website. I'm a full time Django (at al) web developer so I was happy to take on the task.
Going through the specs, they want to control memberships so that all applications need a "second" (read: sponsor, referee, etc) and then they need to pay a subscription fee to be part of the club.
This club has a number of events with variable ticket prices for lunches and talks to name two. Only members are allowed to see the price per ticket and therefore only members are allowed to buy the tickets.
I had originally planned on farming the event management off to EventBrite and pulling the upcoming events back to the website through EB's API but this members-only constraint looks like something EventBrite can't do.
Then there's processing members subscriptions. I had hoped to allow anybody to register a django.contrib.auth account but leave subscription payment offline but the client would be happier if they could mark accounts as "members", store the subscription data in the database and let the members pay online.
Like with EventBrite, I was hoping I could store rough membership data (whether or not they're allowed to subscribe, a unique token for the user on the API service, their level of membership and their membership's expiry) and there'd be something I could post users off to to process their subscription payment.
I basically don't want to touch any payment systems. Even something as simple as Paypal+IPN is something I'd rather not do (I can and have in the past on other projects) but it's the layer of management that I'd have to build around it (messaging members, creating recurring events, etc) that I'd like to farm out to a third party... Even if they do want an additional percent of the payments processed.
Do any of you know any suitable APIs that cover membership or events or both?
Or is this so complex that I should give up hoping for external help and just knuckle down and do it myself?
I think the google search you are looking for is online membership management. I don't know if any of them play particularly nicely with Django/python, but some of them do include APIs. Almost all of these are companies that charge, either for the system, or on a per-user basis.
If you don't mind installing something yourself, CiviCRM is a free, open source solution that I found with a bit of googling. It's integrates with either Joomla or Drupal (so probably PHP-based). You'd have to put the payment processing in yourself, but it does support payments using PayPal which would take handling payments mostly out of the equation. If you can, choose PayPal Express rather than PayPal Website Payments Pro since you may need to be PCI-DSS compliant to use the latter.