Wednesday, August 24, 2016

Update your fork from the original on Github

# Add the remote, call it "upstream":

git remote add upstream

# Fetch all the branches of that remote into remote-tracking branches,
# such as upstream/master:

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

Friday, May 20, 2016

Details over the language for payment gateway


 This isn't a project you would write with PHP. You would need to use a higher level language such as C or C++. Something compiled that will be much faster and more robust then PHP. You can power your web based front end with PHP (i.e. user control panel) but the backend stuff, including payment processing, will need to be in the higher level language. You'll also need an enterprise level database as open source databases could never handle a task like this. Basically you're looking at using an Oracle database which is expensive but also designed for this sort of thing.

There are no tutorials for this because this is a complex job. It's about as complex as a project can get. That's why you can't find any documentation on it.

Your first major issue will be PCI DSS compliance. This is the security practices dictated by the major credit card companies (Visa, MasterCard, Amex, Discover Card, JCB). It dictates how you will secure your data in terms of hardware, software, and practice. It is expensive to do and maintain. You will need to hire a company to certify your compliance on a regularly scheduled basis. Failing your certification can mean you get shut down.

Your second major issue will be getting certified by the processing networks. To be a successful payment gateway you must be certified on every processing platform and there are at least 16 of them that I can think of off of the top of my head. Being certified takes about two months for each. You can do them simultaneously but you would be looking at at least a year to be certified on all of them. And each one has a different API so you will need to code your payment gateway to work with all of them.

Your third major issue will be the data you store. Not only do you have the PCI DSS issues to deal with, but you will need to capture and store every transaction that runs through your system for years. That kind of data will require tons of storage space (that will also need to be secured).

Your fourth major issue will be processing volume. A gateway must be able to perform transactions in a second or less. This means your hardware solutions must be able to scale for heavy traffic especially over the holiday season. It will need to be able to handle hundreds of transactions per second (thousands if you become successful). That is a big reason why you'll need to use a higher level language over PHP.

Your fifth major issue is that you will need to create a powerful yet easy to use API for web developers to use to connect to your payment gateway. They need to be able to do everything a credit card terminal can do through code. Documenting that should be fun! ;)

Minor issues include:

- Making sure you are ECI compliant (Electronic Commerce Indicator is required for all Internet transactions)

- Securing all data transfer (SSL)

- Offering a user control panel

If you want to be successful you will also need to have the following in place:

- Anti-fraud tools

- Have a reseller program in place

My estimations would say it would take 2 - 3 years to build your own payment gateway and get it up and running. That includes being PCI DSS certified, certified on every major processing platform, and to create your API. Costs would be around $250,000 as the developers you would need to write that kind of code will not be cheap plus you will have large infrastructure costs (hardware and software) just to run everything.

Now you can see why nobody new enters this market.

Wednesday, May 18, 2016

ASP.NET Identity 2.1 Roles Based Authorization

Monday, September 28, 2015

"Pending Changes” and “Source Control Explorer” missing from Team Explorer in Visual Studio 2013

To fix the issue simply run the below command in an elevated command prompt as detailed here.
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" /setup
My understanding is this command forces the recreation (what Microsoft refers to as "merging") of current VS settings into what is apparently a corrupt settings cache. On the surface, this is similar to deleting the directory path C:\Users\username\AppData\Local\Microsoft\VisualStudio\version and allowing visual studio to recreate it at launch.
Recently I found this sometimes occurs when I launch several solutions at once (i.e. I have 1 or more Visual Studio instances loading a solution at the same time). I also have ReSharper, SQL Prompt, VSCommands and TFS Power Tools installed which I'm sure contribute to some degree.
This fix should work for all versions of Visual Studio, however you will need to execute the command in the directory appropriate to your version. For example with Visual Studio 2015 the path would be:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe" /setup

Monday, February 16, 2015

Reactive programming in WPF

Project Description
The object of this project is to create a library that offers Functional Reactive Programming abilities to common .Net languages.
With FRP your calculations automatically respond to changes in the underlying data. Obtics includes a live Object Linq and Linq to Xml.

Project Description
Continous LINQ is a .NET Framework 3.5 extension that builds on the LINQ query syntax to create continuous, self-updating result sets. 
In traditional LINQ queries, you write your query and get stale results. With Continuous LINQ, 

you write a query and the results of that query are continuously updated as changes are made to the source collection or items within the source collection. 

CLINQ has tremendous value in GUI development and is especially useful in binding to filtered streams of data such as financial or other network message data.

The Reactive Extensions (Rx) is a library for composing asynchronous and event-based programs using observable sequences and LINQ-style query operators. Using Rx, developers represent asynchronous data streams withObservablesquery asynchronous data streams using LINQ operators, and parameterize the concurrency in the asynchronous data streams using Schedulers. Simply put, Rx = Observables + LINQ + Schedulers.
Whether you are authoring a traditional desktop or web-based application, you have to deal with asynchronous and event-based programming from time to time. Desktop applications have I/O operations and computationally expensive tasks that might take a long time to complete and potentially block other active threads. Furthermore, handling exceptions, cancellation, and synchronization is difficult and error-prone.
Using Rx, you can represent multiple asynchronous data streams (that come from diverse sources, e.g., stock quote, tweets, computer events, web service requests, etc., and subscribe to the event stream using the IObserver interface. The IObservable interface notifies the subscribed IObserver interface whenever an event occurs.
Because observable sequences are data streams, you can query them using standard LINQ query operators implemented by the Observable extension methods. Thus you can filter, project, aggregate, compose and perform time-based operations on multiple events easily by using these standard LINQ operators. In addition, there are a number of other reactive stream specific operators that allow powerful queries to be written.  Cancellation, exceptions, and synchronization are also handled gracefully by using the extension methods provided by Rx.
Rx complements and interoperates smoothly with both synchronous data streams (IEnumerable) and single-value asynchronous computations (Task).
(currently not supported)

Sunday, December 14, 2014

HTML Academy

Powered by Blogger.