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.