webpay-dotnet-sdk

This is Unofficial WebPay .NET SDK. It has some nice features like:

  • Pluggable architecture
  • Unit tested and unit testable
  • Asynchronous actions support

Get Started by downloading it and creating new WebPay payment integration:

        WebPayIntegration wbpayIntegration = new WebPayIntegration(new Configuration
        {
         
            AuthenticityToken = "7db11ea5d4a1af32421b564c79b946d1ead3daf0",
            Key = "dasdsadsa",
            WebPayRootUrl = "https://ipg.webteh.hr",

        });

Parameterize root url, it is different in test and production enviroment.

If you want to make new Purchase transaction message it is simple as writing the following:

            Purchase payment = new Purchase(wbpayIntegration);
          TransactionResult payingResult = payment.MakeTransaction(buyer, order, card, Language.EN);

or

          TransactionResult payingResult = await payment.MakeTransactionAsync(buyer, order, card, Language.EN);

Buyer, Order and Card objects need to be populated by you. If some of that data not meet requirements no data will be sent to WebPay servers and list of validation messages will be returned to you (notice payingResult object - there is RequestValidationErrors property with all validation errors)

While still on payingResult variable take a look how whole TransactionResult object looks like:

 public class TransactionResult
{
    public bool Has3DSecure { get; set; }

    public bool RequestWasSuccessfullyValidated { get; set; }

    public IList<ValidationError> RequestValidationErrors { get; set; }

    public ErrorsResponse WebPayErrors { get; set; }

    public Response.PaymentResponse PaymentResponse { get; set; }

    public SecureMessage SecureMessage { get; set; }

}

RequestValidationErrors is already explained. One similar object is WebPayErrors. WebPayErrors list is populated when validation made upfront thinks everything is ok with request, but WebPay still returns error. To experience this situation send wrong AuthenticityToken property (from WebPayIntegration class). You should get an error "digest is not ok".

When mentioned RequestValidationErrors and WebPayErrors happen to be null or empty that means that either PaymentResponse or SecureMessage objects are populated. Those are populated in success scenario, but keep in mind only one of them is populated. If card has 3DSecure and response was successfull SecureMessage object will be populated and ready for further processing (using 3DSecureHandler class). For convenience Has3DSecure flag is set to true in that case. If card doesn't have 3DSecure and response was successfull, PaymentResponse object will be populated.

If you don't know what is 3d secure on credit card find out here.

Already was mentioned Purchase transaction message. There are 5 transaction message supported by WebPay and this SDK supports them all:

  • Authorize
  • Purchase
  • Refund
  • Void
  • Capture

You can read about them in offical WebPay documentation. Authorize is completely similar to Purchase. It has same response. Response is handled in the same way. Request is the same, except the fact that transaction_type parametar (see documentation) is set to "authorize", rather than "purchase". You don't care about that. Everything is handled for you under the hood.

        Authorization authorizeTransaction = new Authorization(wbpayIntegration);
        TransactionResult result= authorizeTransaction.MakeTransaction(buyer, order, card, Language.EN);

Other 3 transaction message types ( Refund,Void, Capture ) have different request than Authorize and Purchase, but all three have same request when compared to each other (only url to which request is POST-ed is different) Response for all 5 transaction type has same structure.

Capture, Refund and Void have similar way of creating request. Foe example,

        Capture capture = new Capture(wbpayIntegration);
        var result= capture.MakeTransaction(20.0m, Currency.EUR, "1254", Language.EN);
        
        or 
        var result=await capture.MakeTransactionAsync(20.0m, Currency.EUR, "1254", Language.EN);

Althought making transactions is very simple, SDK has very pluggable arhitecture. For example, you can create your own validation rules for validating objects or create your own http client that will make requests to WebPay's servers.

For example, if you want to put your own validation class into action you use another overload of MakeTransaction method, or MakeTransactionAsync method.

        Purchase payment = new Purchase(wbpayIntegration);
        TransactionResult payingResult = payment.MakeTransaction(buyer, order, card, Language.EN, new MyCustomValidator());

where MyCustomValidator must extend IRequestValidator or IRequestValidator, depending on what type of transaction message is. If Authorization or Purchase IRequestValidator is used. In case of Capture, Void, or Refund IRequestValidator is used.

 public class MyCustomValidator : IRequestValidator<PaymentCommitRequest> {

    public MyCustomValidator()
    {
        
    }
     public bool IsValid(PaymentCommitRequest instance){
        return instance.Transation.City.Length>=3 && instance.Transation.City.Length<=30
     }
   public List<ValidationError> DoValidation(PaymentCommitRequest instance){
	         var list=new List<ValidationError>();
         if(instance.Transation.City.Length<3 || instance.Transation.City.Length>30){
	          	var error=new ValidationError();
		          error.ErrorMessage="City must be 3-30 characters long";
	         	list.Add(error);
        }
       return list;
   }     
}

Althought this example doesn't make too much sense in real world (validation exists only for city, and WebPay will still returns errors inside WebPayError property for other things) in some cases this pluggable arhitecture makes sense. For example, when WebPay changes some rules on their side, and this library doesn't follow them with quick update, or simply when you want to make your own rules for validating credit cards or other objects.

Similary you can make your own web client that will make http requests.

Example of usage:

      Authorization authorizeTransaction = new Authorization(wbpayIntegration);
        TransactionResult result= authorizeTransaction.MakeTransaction(buyer, order, card, Language.EN, new PaymentCommitRequestValidator(),new MyWebClient());

PaymentCommitRequestValidator is default validator for validating Authorization and Purchase transaction messages. Capture, Void, and Refund transactions messages have PaymentChangeRequestValidator as default validator, and also their custom web client must extend IPaymentChangeClient rather than IPaymentCommitClient (because those have different request objects; naming comes from the fact that those Refund, Void, Capture transaction messages change transaction is some way.

public class MyWebClient:IPaymentCommitClient
{
    
    public Response<PaymentResponse, SecureMessage> Send(PaymentCommitRequest paymentRequest){
	
	        var paymentRequestComesFirstAsParamater=new PaymentResponse();
		      var secureMessageComesSecondAsParameter=new SecureMessage();
		      return new Response(paymentRequestComesFirstAsParamater,secureMessageComesSecondAsParameter,null,HttpStatusCode.OK,null);
    }

}

Library is made with good intentions and author of SDK is not responsible for any problems that will potentially cause. You are using at your own responsibility.