Wepay integaration for asp.net , c#

The steps followed while implementing wepay in Asp.net application:

1) Wepay offers two type of payments gateway:

    a) Accept payements for your own site.

    b) Let your users accept payments through your application.

Here I had created application to accept payment for own site. We need to register application on WePay stage server.

Go to the application registration page "https://stage.wepay.com/developer/register" and fill in the name, description, and homepage of site. After you click submit you will be shown some details of your application. One of these is an access token. This access token is what lets you make calls to the WePay API

2) Open an account to hold the payments you receive. We can create a new account or we can use the existing account which created when registering your application. To know your account id go to url "https://stage.wepay.com/app". Then select your application and navigate to tab "Details", which consist of all details like ID,Secret,Access_Token,Account_Id.

3) When you user want to pay, redirect them to checkout URI of WePay. We can get this checkout URI using the web service " /v2/checkout/create ". We need to pass some arguments with web service call like

account_id: The unique ID of the account you want the money to go into

amount: The amount you want paid, ex 50.00

short_description: A short description of what the payment is for ex 'donation to Bella's college fund'.

type : GOODS/SERVICE/DONATION/PERSONAL.

redirect_uri: Where the payer will be returned to after making the payment

When we call this service we will recieve  the checkout_id and checkout_uri as a response. We will then send the payer to the checkout_uri so that they can enter their payment information, confirm their payment, and then be returned to your site.

    private void GetCheckoutUri(string accountId, string amount, string desc, string accesstoken)

    {

        string url = @"https://stage.wepayapi.com/v2/checkout/create?account_id=" + accountId + "&amount=" + amount + "&short_description=" + desc + "&type=SERVICE&redirect_uri=http://localhost:2645/ PaymentSuccess.aspx";

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);

        request.Method = "POST";

        request.UserAgent = "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)";

        request.Headers.Add("Authorization", "Bearer "+accesstoken);

        HttpWebResponse myHttpWebResponse = (HttpWebResponse)request.GetResponse();

        Stream streamResponse = myHttpWebResponse.GetResponseStream();

        StreamReader streamRead = new StreamReader(streamResponse);

        Char[] readBuff = new Char[256];

        int count = streamRead.Read(readBuff, 0, 256);

        string jsonstring = string.Empty;

        while (count > 0)

        {

            String outputData = new String(readBuff, 0, count);

            jsonstring += outputData.ToString();

            count = streamRead.Read(readBuff, 0, 256);

        }

        string[] codes = jsonstring.Split(',');

        string checkOutUri = codes[1].Replace("\"", "").Replace("checkout_uri:", "").Replace("}", "");

        // Release the response object resources.

        streamRead.Close();

        streamResponse.Close();

        myHttpWebResponse.Close();

        Response.Redirect(checkOutUri, false);

    }

4) When user has confirm their payment, and returned to our site, we can show them the receipt of payment. To get the payment details we need to call the web service “/checkout/” with parameter checkout_id in response we get the following :

checkout_id : The unique ID of the checkout.

account_id: The unique ID of the account that the money will go into.

state: The state the checkout is in. See the API object state section for a listing of all states.

short_description: The short description of the checkout. Max 127 chars.

long_description: The long description of the checkout (if available). Max 2047 chars.

currency: The currency used (always "USD" for now).

amount: The dollar amount of the checkout object (ex. 3.50). This will always be the amount you passed in /checkout/create

fee: The dollar amount of the WePay fee.

gross: The total dollar amount paid by the payer.

app_fee: The dollar amount that the application received in fees. App fees go into the API application's WePay account.

fee_payer: Who is paying the fee (either "payer" for the person paying or "payee" for the person receiving the money).

reference_id: The unique reference_id passed by the application (if available).

redirect_uri: The uri the payer will be redirected to after payment (if available). Max 2083 chars.

callback_uri: The uri which Instant Payment Notifications will be sent to. Max 2083 chars.

payer_email: The email address of the person paying (only returned if a payment has been made).

payer_name: The name of the person paying (only returned if a payment has been made).

cancel_reason: If the payment was canceled, the reason why.

refund_reason: If the payment was refunded the reason why.

auto_capture: Default is true. If set to false then the payment will not automatically be released to the account and will be held by WePay in payment state 'reserved'. To release funds to the account you must call /checkout/capture

require_shipping: Default is false. If set to true then the payer will be required to enter their shipping address when paying.

shipping_address: If 'require_shipping' was set to true and the payment was made, this will be the shipping address that the payer entered. It will be in the following format:

{"address1":"380 Portage Ave","address2":"","city":"Palo Alto","state":"CA","zip":"94306","country":"US"}

tax: The dollar amount of taxes paid.

amount_refunded: If this checkout has been fully or partially refunded, this has the amount that has been refunded so far.

create_time: The unixtime when the checkout was created.

    private void GetCheckoutStatus(string checkout_id )

    {

        string url = @"https://stage.wepayapi.com/v2/checkout?checkout_id=" + checkout_id;

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);

        request.Method = "POST";

        request.UserAgent = "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)";

        request.Headers.Add("Authorization", "Bearer " + Session["accesstoken$"].ToString());

        HttpWebResponse myHttpWebResponse = (HttpWebResponse)request.GetResponse();

        Stream streamResponse = myHttpWebResponse.GetResponseStream();

        StreamReader streamRead = new StreamReader(streamResponse);

        Char[] readBuff = new Char[256];

        int count = streamRead.Read(readBuff, 0, 256);

        string jsonstring = string.Empty;

        while (count > 0)

        {

            String outputData = new String(readBuff, 0, count);

            jsonstring += outputData.ToString();

            count = streamRead.Read(readBuff, 0, 256);

        }

        string[] codes = jsonstring.Split(',');

       // Release the response object resources.

        streamRead.Close();

        streamResponse.Close();

        myHttpWebResponse.Close();

       createpaymentreciept(codes);

       

    }

we get the all details of payment as response in string “codes”. We can now design the payment receipt as required in the method ”createpaymentreciept”.We get the payment state in one of the following stages:

new  The checkout was created by the application

authorized The payer entered their payment info and confirmed the payment on WePay

reserved The payment has been reserved from the payer

captured The payment has been credited to the payee account

settled The payment has been settled and no further changes are possible

cancelled The payment has been cancelled by the payer, payee, or application

refunded The payment was captured and then refunded by the payer, payee, or application. The payment has been debited from the payee account.

charged back The payment has been charged back by the payer and the payment has been debited from the payee account.

 Failed The payment has failed.

Expired Checkouts get expired if they are still in state new after 30 minutes (i.e., they have been abandoned).

Improving the performance of Asp.Net web application

Many a times we face performance problems in our Asp.Net web application. Sometimes the page hangs or the server takes too much time in processing a page or when many users hit the application the application hangs or some pages take more time than others even though they are roughly same in size etc. Not only these but many more issues are there which one encounter with Asp.Net application in regard to performance.

There are many reasons for it but if we keep some key points in mind while designing and developing the web application we can easily over-come these performance issues. For this I have made out a list of 20 tips which if one keeps in mind and implement it there would be no performance issue for the Asp.Net web application. The list of 20 tips is as follows:

1)Turn off Tracing unless until required

Tracing is one of the wonderful features which enable us to track the application's trace and the sequences. However, again it is useful only for developers and you can set this to "false" unless you require to monitor the trace logging. Enabling tracing adds performance overhead and might expose private information, so it should be enabled only while an application is being actively analyzed. 

When not needed, tracing can be turned off using:

<trace enabled="false" localonly="”true”"

pageoutput="”false”" requestlimit="”10”"

tracemode="”SortByTime”">

2) Check if client is connected before performing any large operation

Take advantage of HttpResponse.IsClientConnected before performing a large operation:

if (Response.IsClientConnected)
{
// If still connected, redirect to another page. 
Response.Redirect("Page2CS.aspx", false);
}


3) Disable View State of a Page if possible 

View state is a fancy name for ASP.NET storing some state data in a hidden input field inside the generated page. When the page is posted back to the server, the server can parse, validate, and apply this view state data back to the page's tree of controls. 
View state is a very powerful capability since it allows state to be persisted with the client and it requires no cookies or server memory to save this state. Many ASP.NET server controls use view state to persist settings made during interactions with elements on the page, for example, saving the current page that is being displayed when paging through data. 

There are a number of drawbacks to the use of view state, however. It increases the total payload of the page both when served and when requested. There is also an additional overhead incurred when serializing or deserializing view state data that is posted back to the server. 
View state increases the memory allocations on the server. Several server controls, the most well known of which is the DataGrid, tend to make excessive use of view state, even in cases where it is not needed.

Pages that do not have any server postback events can have the view state turned off. 
The default behavior of the ViewState property is enabled, but if you don't need it, you can turn it off at the control or page level. Within a control, simply set the EnableViewState property to false, or set it globally within the page using this setting: 

<%@ Page EnableViewState="false" %> 

If you turn view state off for a page or control, make sure you thoroughly test your pages to verify that they continue to function correctly. 


4) Turn off Session State, if not required 

One extremely powerful feature of ASP.NET is its ability to store session state for users, such as a shopping cart on an e-commerce site or a browser history. 

Since ASP.NET Manages session state by default, you pay the cost in memory even if you don't use it. I.e. whether you store your data in in-process or on state server or in a Sql Database, session state requires memory and it's also time consuming when you store or retrieve data from it. 

You may not require session state when your pages are static or when you do not need to store information captured in the page. In such cases where you need not use session state, disable it on your web form using the directive

<@%Page EnableSessionState="false"%> 

In case you use the session state only to retrieve data from it and not to update it, make the session state read only by using the directive, 

<@%Page EnableSessionState ="ReadOnly"%>


5) Set debug=false in web.config 

When you create the application, by default this attribute is set to "true" which is very useful while developing. However, when you are deploying your application, always set it to "false". 

Setting it to "true" requires the pdb information to be inserted into the file and this results in a comparatively larger file and hence processing will be slow. Therefore, always set debug="false" before deployment. 


6) Use the String builder to concatenate string 

String is Evil when you want to append and concatenate text to your string. All the activities you do to the string are stored in the memory as separate references and it must be avoided as much as possible, i.e. When a string is modified, the run time will create a new string and return it, leaving the original to be garbage collected. Most of the time this is a fast and simple way to do it, but when a string is being modified repeatedly it begins to be a burden on performance: all of those allocations eventually get expensive. 

Use String Builder when ever string concatenation is needed so that it only stores the value in the original string and no additional reference is created. 


7) Use gzip compression on IIS

While not necessarily a server performance tip (since you might see CPU utilization go up), using gzip compression can decrease the number of bytes sent by your server. This gives the perception of faster pages and also cuts down on bandwidth usage. Depending on the data sent, how well it can be compressed, and whether the client browsers support it (IIS will only send gzip compressed content to clients that support gzip compression, such as Internet Explorer 6.0 and Firefox), your server can serve more requests per second. In fact, just about any time you can decrease the amount of data returned, you will increase requests per second.
The good news is that gzip compression is built into IIS 6.0 and is much better than the gzip compression used in IIS 5.0. Unfortunately, when attempting to turn on gzip compression in IIS 6.0, you may not be able to locate the setting on the properties dialog in IIS. The IIS team built awesome gzip capabilities into the server, but neglected to include an administrative UI for enabling it. To enable gzip compression, you have to spelunk into the innards of the XML configuration settings of IIS 6.0.


8) Page Output Caching and Proxy Servers

ASP.NET is your presentation layer (or should be); it consists of pages, user controls, server controls (HttpHandlers and HttpModules), and the content that they generate. If you have an ASP.NET page that generates output, whether HTML, XML, images, or any other data, and you run this code on each request and it generates the same output, you have a great candidate for page output caching.
By simply adding this line to the top of your page:

<%@ Page OutputCache VaryByParams="none" Duration="60" %> 

You can effectively generate the output for this page once and reuse it multiple times for up to 60 seconds, at which point the page will re-execute and the output will once be again added to the ASP.NET Cache. This behavior can also be accomplished using some lower-level programmatic APIs, too. There are several configurable settings for output caching, such as the VaryByParams attribute just described. VaryByParams just happens to be required, but allows you to specify the HTTP GET or HTTP POST parameters to vary the cache entries. For example, default.aspx?Report=1 or default.aspx?Report=2 could be output-cached by simply setting VaryByParam="Report". Additional parameters can be named by specifying a semicolon-separated list.

Many people don't realize that when the Output Cache is used, the ASP.NET page also generates a set of HTTP headers that downstream caching servers, such as those used by the Microsoft Internet Security and Acceleration Server or by Akamai. When HTTP Cache headers are set, the documents can be cached on these network resources, and client requests can be satisfied without having to go back to the origin server.

Using page output caching, then, does not make your application more efficient, but it can potentially reduce the load on your server as downstream caching technology caches documents. Of course, this can only be anonymous content; once it's downstream, you won't see the requests anymore and can't perform authentication to prevent access to it.


9) Per - Request Caching

Whereas the Cache API is designed to cache data for a long period or until some condition is met, per-request caching simply means caching the data for the duration of the request. A particular code path is accessed frequently on each request but the data only needs to be fetched, applied, modified, or updated once. This sounds fairly theoretical, so let's consider a concrete example.

In the Forums application of Community Server, each server control used on a page requires personalization data to determine which skin to use, the style sheet to use, as well as other personalization data. Some of this data can be cached for a long period of time, but some data, such as the skin to use for the controls, is fetched once on each request and reused multiple times during the execution of the request.

To accomplish per-request caching, use the ASP.NET HttpContext. An instance of HttpContext is created with every request and is accessible anywhere during that request from the HttpContext.Current property. The HttpContext class has a special Items collection property; objects and data added to this Items collection are cached only for the duration of the request. Just as you can use the Cache to store frequently accessed data, you can use HttpContext.Items to store data that you'll use only on a per-request basis. The logic behind this is simple: data is added to the HttpContext.Items collection when it doesn't exist, and on subsequent lookups the data found in HttpContext.Items is simply returned.


10) Connection Pooling

Setting up the TCP connection between your Web application and SQL Server™ can be an expensive operation. Developers at Microsoft have been able to take advantage of connection pooling for some time now, allowing them to reuse connections to the database. Rather than setting up a new TCP connection on each request, a new connection is set up only when one is not available in the connection pool. When the connection is closed, it is returned to the pool where it remains connected to the database, as opposed to completely tearing down that TCP connection.

Of course you need to watch out for leaking connections. Always close your connections when you're finished with them. I repeat: no matter what anyone says about garbage collection within the Microsoft® .NET Framework, always call Close or Dispose explicitly on your connection when you are finished with it. Do not trust the common language runtime (CLR) to clean up and close your connection for you at a predetermined time. The CLR will eventually destroy the class and force the connection closed, but you have no guarantee when the garbage collection on the object will actually happen.

To use connection pooling optimally, there are a couple of rules to live by. First, open the connection, do the work, and then close the connection. It's okay to open and close the connection multiple times on each request if you have to (optimally you apply Tip 1) rather than keeping the connection open and passing it around through different methods. Second, use the same connection string (and the same thread identity if you're using integrated authentication). If you don't use the same connection string, for example customizing the connection string based on the logged-in user, you won't get the same optimization value provided by connection pooling. And if you use integrated authentication while impersonating a large set of users, your pooling will also be much less effective. The .NET CLR data performance counters can be very useful when attempting to track down any performance issues that are related to connection pooling.

Whenever your application is connecting to a resource, such as a database, running in another process, you should optimize by focusing on the time spent connecting to the resource, the time spent sending or retrieving data, and the number of round-trips. Optimizing any kind of process hop in your application is the first place to start to achieve better performance. The application tier contains the logic that connects to your data layer and transforms data into meaningful class instances and business processes. For example, in Community Server, this is where you populate a Forums or Threads collection, and apply business rules such as permissions; most importantly it is where the Caching logic is performed.


11) Return Multiple ResultSets

Review your database code to see if you have request paths that go to the database more than once. Each of those round-trips decreases the number of requests per second your application can serve. By returning multiple resultsets in a single database request, you can cut the total time spent communicating with the database. You'll be making your system more scalable, too, as you'll cut down on the work the database server is doing managing requests.

While you can return multiple resultsets using dynamic SQL, I prefer to use stored procedures. It's arguable whether business logic should reside in a stored procedure, but I think that if logic in a stored procedure can constrain the data returned (reduce the size of the dataset, time spent on the network, and not having to filter the data in the logic tier), it's a good thing. Using a SqlCommand instance and its ExecuteReader method to populate strongly typed business classes, you can move the resultset pointer forward by calling NextResult.


12) Avoid throwing exceptions 

Exceptions are probably one of the heaviest resource hogs and causes of slowdowns you will ever see in web applications, as well as windows applications. You can use as many try/catch blocks as you want. Using exceptions gratuitously is where you lose performance. For example, you should stay away from things like using exceptions for control flow. 


13) Use Finally Method to kill resources 
The finally method gets executed independent of the outcome of the Block. Always use the finally block to kill resources like closing database connection, closing files and other resources such that they get executed independent of whether the code worked in Try or went to Catch.


14) Avoid unnecessary round trips to the server - Where-ever feasible use AJAX

Round trips significantly affect performance. They are subject to network latency and to downstream server latency. Many data-driven Web sites heavily access the database for every user request. While connection pooling helps, the increased network traffic and processing load on the database server can adversely affect performance. 

Keep round trips to an absolute minimum. Implement Ajax UI whenever possible. The idea is to avoid full page refresh and only update the portion of the page that needs to be changed 


15) Use Page.ISPostBack 

Make sure you don't execute code needlessly. Use Page.ISPostBack property to ensure that you only perform page initialization logic when a page is first time loaded and not in response to client postbacks. 


16) Always check Page.IsValid when using Validator Controls

So you’ve dropped on some validator controls, and you think your good to go because ASP.net does everything for you! Right? Wrong! All that happens if bad data is received is the IsValid flag is set to false. So make sure you check Page.IsValid before processing your forms.


17) Use low cost authentication 

Authentication can also have an impact over the performance of your application. For example passport authentication is slower than form-base authentication which in here turn is slower than Windows authentication. 


18) Make JavaScript and CSS External 

Using external files generally produces faster pages because the JavaScript and CSS files are cached by the browser. Inline JavaScript and CSS increases the HTML document size but reduces the number of HTTP requests. With cached external files, the size of the HTML is kept small without increasing the number of HTTP requests thus improving the performance.


19) Avoid Server-Side Validation

Try to avoid server-side validation, use client-side instead. Server-Side will just consume valuable resources on your servers, and cause more chat back and forth. Only implement server-side validation on important fields.


20) Minimize the number of web server controls 

The use of web server controls increases the response time of your application because they need time to be processed on the server side before they are rendered on the client side. One way to minimize the number of web server controls is to taking into consideration, the usage of HTML elements where they are suited, for example if you want to display static text.


The list is not exhaustive, it just discusses the 20 top performance tips. If you have any other tip do share it.