Ekspres Bank

Document Logs
Change log:

Date:	Author:	Version:	Changes:	Completed	Ext.	Int.	Is in Core
		1.0	Doc. created	Yes	X
			Doc updated: EkspresBank integration upgraded to use new API	In-progress

Terms and definitions:

1 - Purpose of Document

This document provides the overall technical details and design of implementing and using the functionality as specified in section 2 - Introduction. This document will not cover implementation details – for this the code base should be inspected.

2 - Introduction to Functionality

Ekspres bank is a company that can help finance a purchase by supplying a 'loan' during the purchase phase.

This means that the customer buys a phone during sign up. The customer chooses to buy through Ekspres bank who then pays for the phone.

The customer now has a 'loan' at Ekspres bank that the customer will pay back outside our system.

The process is done through three steps.

1. The customer chooses to use Ekspres bank, and a container for the purchase is created at Ekspres bank to Initiate the Application through a SOAP call to PrefillingService. Note: CDRator integration to Ekspres Bank API does not support this part, since it has been agreed that an external web service hosted by customer will take care of this.
2. The customer application is the approved or rejected by Ekspres Bank. To get the application status information, Ekspres Bank is polled for a status of the purchase through a call to SOAP service: FeedbackService. The method called is getApplicationStatus.
3. If the customer is approved, Rator acknowledges the purchase and sends a capture message to Ekspres bank through SOAP service FeedbackService. To achieve this, putEventRecord  method from FeedbackService is called with parameter EventType="282"
4. It is also possible to cancel the purchase through SOAP service FeedbackService. To cancel the application, the method putEventRecord should be invoked with parameter EventType="401". Note: It is possible to cancel the application via FeedbackService only if the Application is not yet marked as Shipped (capture signal not yet sent). Once the application has been marked as shipped, the FeedbackService can no longer be used to cancel the application. In that case, the cancellation can be requested manually via Ekspres Bank Sales support and should be initiated by the partner. CDRator is not involved in/responsible for such manual cancellations.

The Ekspres Bank API integration is implemented and can be found at:

https://svn.cdrator.com/svn/dev/integration/Financial/DK/EkspresBank/trunk

Maven dependency:

<groupId>com.cdrator.integration.financial</groupId>
<artifactId>rator-financial-dk-ekspresbank</artifactId>

3 - API

The Ekspres bank API can be accessed through the workflow actions developed in CDRator integration project. 

3.1 - Workflow Actions

3.1.1 - GetApplicationStatusAction

FQCN of the action class: com.CDRator.billing.financial.ekspresbank.action.GetApplicationStatusAction

This action will poll for the status of an application referenced by the supplied ApplicationGUID.

Input Arguments

The action takes three arguments:

public ApplicationStatusResult execute(String applicationGUID, String applicationId, String brandId) throws Exception

applicationGUID:  The unique ID that is used to reference an application.

applicationId: Application Id. 

brandId:  Used to read the Branded parameters. The URL of the webservice at Ekspres bank and some additional required arguments are specified in the parameter tree. So brand Id is used on a branded environment.

Important Note: When using the GetApplicationStatusAction, do not supply both ApplicationGuid and ApplicationId. Only supply ApplicationGuid.

Return value

This action returns an object of type ApplicationStatusResult. Helper methods exposed by this object can be used to map the result to relevant outcomes based on business requirements. The table below describes all helper methods that can be invoked on this result object with a description of the return value for each of these methods. 

If anything unexpected happens, an exception is thrown. It is possible to map an Exception to an outcome on the Action GUI on the workflow builder. 

3.1.2 - CancelAction

FQCN of the action class: com.CDRator.billing.financial.ekspresbank.action.CancelAction

This action is used to send a Cancel signal to Ekspresbank to cancel the sale. Cancel can be initiated via this action only if the Ship Signal for this application is not yet sent to Ekspres Bank.

Input Arguments

This action takes in three arguments:

public CancelResult execute(String applicationGUID, Date eventDate, String brandId) throws Exception

applicationGUID:The unique ID that is used to reference an application.

eventDate: Time of cancellation of the Application. Ekspres Bank expects a non-null value for eventDate. Hence, the action will use current date if eventDate supplied in the input is null.

brandId: Used to read the Branded parameters. The URL of the webservice at Ekspres bank and some additional required arguments are specified in the parameter tree. So brand Id is used on a branded environment.

Return value

This action returns an object of type CancelResult. Helper methods exposed by this object can be used to map the result to relevant outcomes based on business requirements. The table below describes all helper methods that can be invoked on this result object with a description of the return value for each of these methods. 

If anything unexpected happens, an exception is thrown. It is possible to map an Exception to an outcome on the Action GUI on the workflow builder. 

3.1.3 - CaptureAction

FQCN of the action class: com.CDRator.billing.financial.ekspresbank.action.CaptureAction

This action is used to send a Ship signal to Ekspresbank, and the payout process is initiated.

Input Arguments

This action takes in three arguments:

public CaptureResult execute(String applicationGUID, Date eventDate, String brandId) throws Exception

applicationGUID: The unique ID that is used to reference an application.

eventDate: Time of physical shipment of the goods. Ekspres Bank expects a non-null value for eventDate. Hence, the action will use current date if eventDate supplied in the input is null.

brandId:  Used to read the Branded parameters. The URL of the webservice at Ekspres bank and some additional required arguments are specified in the parameter tree. So brand Id is used on a branded environment.

Return value

This action returns an object of type CaptureResult. Helper methods exposed by this object can be used to map the result to relevant outcomes based on business requirements. The table below describes all helper methods that can be invoked on this result object with a description of the return value for each of these methods. 

If anything unexpected happens, an exception is thrown. It is possible to map an Exception to an outcome on the Action GUI on the workflow builder. 

3.2 - Exceptions thrown by Workflow Actions

Following exceptions can be thrown by Ekspres Bank workflow actions:

• com.CDRator.billing.financial.ekspresbank.action.result.exception.ResultNullException: Extends from java.lang.Exception. This exception is thrown when null response is received from Ekspres Bank. 
• com.CDRator.billing.financial.ekspresbank.action.result.exception.InvalidApplicationGUIDException: Extends from java.lang.Exception. If the ApplicationGUID supplied in the input parameters is null/empty, then the action throws this exception. ApplicationGUID is mandatory to invoke Status poll/cancel/capture functions of Ekspres Bank API.
• java.lang.Exception: Sysexceptions due to missing parameter tree entries or other checked exceptions are grouped here
• java.lang.RuntimeException: Any runtime exception 

4 - Logging

The project uses the rator-soap-monitoring to log request and response to the SOAP_CLIENT_LOG table. In order for this logging to work, two parameters must be added to the parameter tree. See section Configuration.

5 - Configuration

The table below describes all parameter tree entries that are used for Ekspres Bank API integration. All parameters except the logging related parameters are brand-enabled.

Some of the Parameters are mandatory and some are optional. The mandatory parameters must always be created and should contain proper values. The Optional parameters can be omitted. If an optional parameter is not present, a default value (if available) is used instead. Default values (if any) for optional parameters are mentioned in the table. If the default value does not meet the requirements, then the corresponding optional parameter can be created and set to desired value as per business requirements. 

Parameters Used for communicating with Ekspres bank :

Parameters Required for Logging SOAP request, response XMLs to the SOAP_CLIENT_LOG

6 - Version