Nothing to see...

A simple blog about all things in the world that is ridikulouse.

Technological steps, are man kinds greatest achievements

Not a Fighter, but a lover of Tech.

Love of the internet

The Internet is the final frontier for open connected networks, it promotes speech and advances knowledge for any mere person. The internet is fast becoming a need rather a want, and it is recognised by the UN as a necessity for the modern person.

Photography

Photography is more than just Art and expression, it is the manipulation of the light and provokes emotion and memories.

Have a look around

The articles on this blog represent my thoughts and views at the time of writing, I can always change my views through further education...please don't hold me against my views. Some of the articles have been written to assist anyone else with similar issues - it also helps me to remember. Hope you get something out of this.

Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

Tuesday, January 20, 2015

Working with the Paypal Classic API Samples

When I started the the Classic API Samples I had to do the following operations for Visual Studio 2013:

  1. Open the solution by double clicking on the .sln file via Exporer (or open it directly from Visual Studio)
  2. Visual Studio will prompt you about one way migration, accept it and continue
  3. Set the .NET Framework to 4.5.2 as it suggests

When you run the application it will work to a point - I noticed that the order that the main() executes the calls is not in the right order. Also, I noticed that there was a number of items that was hardcoded.

For example, the SetExpressCheckoutSamplewas further down, and CreateRecurringPaymentsProfileSample and DoCaptureSample were ahead of it. In terms of the order of operations this doesn't really make any sense since the Customer has not authorised anything they would have clicked submit on your page. 

The tokens that are used were also hardcoded, this is ok for the initial test - but Paypal really should have paid more attention to this. Since this will get Newbie (such as myself unstuck). 

To resolve this, I had to store the token once SetExpressCheckoutSample.SetExpressCheckoutAPIOperation() is executed. I then had to pass the token into where ever the token was being referred to. 

For example, in GetExpressCheckoutDetailsSample I overloaded the constructor to take in a string:

public string tk {get; set;}


public GetExpressCheckoutDetailsSample(string tk)
    {
        this.token = tk;
    }

Please note that this is to try and get the samples to actually work only. 

Then, I replaced GetExpressCheckoutDetailsRequestType getExpressCheckoutDetailsRequest = new GetExpressCheckoutDetailsRequestType("EC-11U13522TP7143059"); with 

GetExpressCheckoutDetailsRequestType getExpressCheckoutDetailsRequest = new GetExpressCheckoutDetailsRequestType(this.token);

As you can see above the Token was hardcoded, by passing the this.token instead of the hardcoded value I could use what I had set previously in SetExpressCheckoutSample.

Unfortunately the Classic API sample is a console application, after making these changes I was expecting the PayerID to be printed. When I found that this didn't actually print out anything and debugging and checking google. I noticed that there was a comment above the Console.WriteLn stating:

"
// Unique PayPal Customer Account identification number. This
                    // value will be null unless you authorize the payment by
                    // redirecting to PayPal after `SetExpressCheckout` call.

"

Good work Paypal, why would you provide a sample without actually providing a working sample? This sample should have been a asp.net sample, with the appropriate redirection routine. 

I'm positing this as I progress - however, I may need to alter posts as I learn more.

Thanks

The Joys of Paypal Integeration and Financials Transactions

If you are like me, you live in a country that you could say is technologically challenged. I face this problem on daily, weekly, monthly basis whenever I want to try something that is out there, only to find out that it is restricted to USA.

In the global age of the internet I find it Ridikulouse that these types of restrictions apply. I know that in financial situations you have to be careful, and there are a number of regulations that bind us in the way we do things. And I received a harsh cup of reality and  realised this when I started to look at integrating payments processing for project that I'm working on.

I initially wanted to roll my own, and since I'm in the development phase and the interest of the project comes and goes - I have very little money to spend. I cannot spend on subscriptions and jump through hoops one month and loose all interest (change priorities the next month), and then back on the bandwagon the following month.

In this instance I was still in the very much interested phase, so I looked around on how I can roll my own. I soon realised that rolling your own meant that you need Internet Merchant Account - for which you need file applications to a Financial Institutions, who wants to understand your business in detail and requests for a Business Plan etc... All this just to develop. Then it was the payment processors, most want you to sign up straight away and let them know which plan you want to go on to. But I'm still developing my idea.

I then thought of Paypal, I was almost about to go onto Crytocurrency payments which felt a whole lot easier than the getting an Internet Merchant Account. I digress, back to Paypal. I thought of Paypal as a mechanism of accepting and processing the payment - sounded like a brilliant idea. I read article after article on how developer centric they were, and its free to set up a test account. So I did, I created a test account on their sandbox system - everything was falling into place. The next hurdle was the type of product and features that I wanted, this is probably where everything started to fall over.

Its been about two weeks now of researching Paypal alone - the developer centricity that I thought of wasn't actually there. Paypal, from what I can see has spread themselves out way too thin. They have

  1. Information on their site that is out of date
  2. Information that is missing (i.e demo video gives a 404)
  3. Product Names that are confusing (Website Payment Pro, which should not be confused with Payment Pro or Payflow Pro ) - to be fair they do clearly state to customers not be confused with these names.
  4. Git Repos that are out of date
  5. Confusing messaging (Paypal states that they will continue to support the development of the Classic API and when you goto the GIT Repo of their SDK it states that this is now defunct and for everyone to use REST API - REST API is limited and available in USA, CANADA and the United Kingdom).
  6. They also have source code that was not complete (see statement  paymentItem.ItemCategory = (ItemCategoryType)EnumUtils.GetValue(, typeof(ItemCategoryType)); )
  7. They don't really support Asp.net MVC... 

To make matters worse i went to Stackoverflow to get assistance, and it doesn't look like that Paypal area gets any love. My question there is still unanswered. Paypal integration is a real struggle, payment processing in general is a struggle. I'll write more as I know more (see the paypal label on the side of this post to see all the other posts about paypal). At this stage I'm still clueless.