I am checking feasibility of our application with Sage Pay
Our application is a thick Desktop based software having no Web-Page or integration to website.
All of following 4 options on Sage Pay website
Form integration
Server integration
Serve Inframe integration
Direct integration
are seems to be working around web-pages
Here I am only looking if SagePay solution is feasible or not because we do not have any website to take payments.
We need to facilitate payments to be taken into our desktop software
thanks in advance
Avtar
Sage Pay Direct doesn't rely on pages; it can be used in a smart client application. You just need to make sure you set the transaction type as MOTO (Mail Order Telephone Order), I think M, so that the 3D secure dialogs aren't shown.
You're right in that all the other mechanisms will require a browser.
Remember, with Sage Pay Direct you fall directly in the net of PCI DSS compliance, so you'll probably want to make sure that you remain on the right side of that.
Related
I'm trying to implement Google pay on the web by this example: https://developers.google.com/pay/api/web/guides/paymentrequest/tutorial.
When I remove "PAN_ONLY" from the example code, the button becomes invisible on my PC and on smartphone.
Under what conditions with the authentication method "CRYPTOGRAM_3DS" payment will be available?
I'm using the latest version of Google Chrome.
Tokenized cards are only available from your Android device today, where there are the means to securely authenticate the transaction and store sensitive information related to your forms of payment.
There are initiatives in the industry aiming at adding means of security and second factors to the web. These are expected to help the utilization of tokenization on the Web too.
I have a requirement where I need to develop a web application in which two application users negotiate with each and later after agreeing on terms they are to trade illiquid bonds via Bloomberg. For this I need to generate the BXT and SXT Trade Tickets through my application. The question really is that is this even possible without the Terminal?
A white paper on Bloomberg API's website says
Other applications are possible, for example submissions of trade orders
But I am not able to find any reference or example how this can be achieved using Bloomberg API or any other service provided by Bloomberg.
I'd be surprised if you are able to do this, by definition a web application is hosted on server x and interacted with from device y. Bloomberg's entire business model is based around having a Bloomberg terminal on device y.
I'd recommend you look at other bond trading platforms not just Bloomberg, e.g. TradeWeb, MarketAxess or even the large brokers e.g. ICAP, Tullett who may have a more suitable API.
This might come a little bit late but you might want to have a look into Bloomberg's FIX API. I am working on a similar project and I have implemented this functionality in a web application that creates and sends Trade Tickets via FIX. You do not have to have a Bloomberg terminal installed. Your FIX session will connect directly to a Bloomberg FIX endpoint.
Bloomberg has a test environment for this. You have to contact one of their representatives and ask for a Beta FIX Session.
FIX is a publicly available protocol for exchanging financial information. A good starting point would be https://en.wikipedia.org/wiki/Financial_Information_eXchange
There are a number of free finance tracking sites out there like mint.com, wesabe.com etc.. .
I've tried all of them and all seem to miss the mark in one way or another. I'm interested in creating my own website, or possibly just a stand alone windows program for tracking my finances in ASP.NET or C#.NET.
I'm assuming the answer is no, but is there any way that a personal developer can download transactions from financial websites like these? I know once you login to most financial sites you can download a CSV or Quicken file. Yet I really like how I can log-in to my Mint.com account and update all my accounts with one click.
Popular applications (like Quicken) and most major US banks support Open Financial Exchange (OFX). If a bank can connect to Quicken, it probably supports OFX (though not guaranteed).
I doubt very many banks have public APIs for this. More likely than not, you will need to send HTTPS requests to the various banking websites, and you will probably have to have custom code for each bank that you wish to support, tailored to the structure of their websites and their form elements.
I am developing software which I want to sell online. The typical pay the vender, get a digital key that unlocks the application scenario.
I've never set this up before, does anyone have any info on good service providers, and things I need to know when setting this up?
Microsoft uses digital river, maybe check them out?
You can checkout a typical license acquisition flow using FastSpring
FastSpring / NetLicensing flow
This combines FastSpring e-Commerce and NetLicensing license management.
You did not say what language you are planning on using, but this is a great solution for a .net compiled language:
http://xheo.com/products/copy-protection
It provides two key features. First the ability to automatically generate your licenses based on many different ecommerce solutions so you don't have to keep paying a 3rd party a % for it. Second, it offers code protection to prevent people from using Reflection on your software to crack it / steal your intellectual rights. (note i said prevent, not completely stop)
I'm using FastSpring, you give them binary file and keys, and you setup your account to send an email that contains these two informations. you can tell them what you want and they will do it for you
I have tried calling PayPal themselves, and the rep on the phone didn't even know Payflow Link could work this way, so I don't trust his advice. All my searching has encountered mixed answers.
I am building an ecommerce site using Payflow Link, where the CC processing is handled on Paypal hosted pages. However, I am consider implementing the advanced integration method, whereby customers input all the CC info on a form hosted by my server, but the form gets POST'ed over SSL directly to Paypal's servers. Using this method, I can maintain the branding of my site except for the required Paypal reciept page.
The CC information, using this method, should never touch my servers. Are they required to be PCI compliant? From a technical standpoint, I can't see why it should, but from a legal standpoint, I get lost in the jargon of the PCI-DSS documents. The site does roughly 1000 transactions a year.
I'm exploring the same issue. From talking to our PCI compliance vendor, it sounds like MikeH is incorrect. Because we're hosting the form on our web site, the server itself needs to be PCI compliant. That's because the form could be hacked if the server is not secure.
I see two options:
Keep the form on our site. Make the server secure (our web host does not currently pass the PCI scan, they are working on it). Fill in the much longer and detailed SAQ Validation Type 5 (Questionnaire D).
Use Payflow Link's credit card capture form. Won't need to worry about the server, can then use the much shorter SAQ Validation Type 1 (Questionnaire A). But, we lose branding and may lose sales because the Payflow Link pages look so different.
The SAQ D is ugly :-(
Using the model you are proposing, you do indeed have to be PCI-compliant, but at a much less restrictive level than you would if the data touched your server.
For details, goto https://www.pcisecuritystandards.org/saq/instructions_dss.shtml and click on the link for SAQ Validation Type 1 (Questionnaire A). This will tell you exactly what parts of the PCI DSS you must implement as a merchant with all cardholder functions outsourced.
Hope this helps!
If you accept credit card payments through your website you have to be PCI compliant. How far you need to go will vary depending on your implementation. If you're hosting the form that the users are using to make payments you need to use an SSL certificate so that page is encrypted (even if only to make sure the lock icon appears in the user's browser. Without it you won't be doing 1000 transactions per year anymore).