APEXX Core Integration Guide



Introduction

This guide provides an overview of the Apexx Core Technical System and details of how to integrate to the Direct API. The Direct API defines a server-to-server specification for sending messages directly to the APEXX CORE Platform.

The guide assumes that the reader has an understanding of the payment service industry, data communications and how to connect to third-party solutions. The audience for this document includes technical integration teams and developers who wish to process transactions through the APEXX CORE Platform.

Technical Pre-Requisite

Content Type and Encoding

All API calls are performed over standard HTTPS GET/POST call. The HTTPS request must use UTF-8 encoding. The content type should be set as “text/html” and HTTPS header must contain this digest. For test, the connection may be standard HTTP

JSON

Authentication Request is JSON based. Your system should have the capability of processing JSON from your side

Payment API Details

Apexx Core provides numerous connections to hosted payment pages on the various payment gateways and acquirers. Merchants are required to have merchant accounts with the Payment Companies, which the Merchant wishes to utilise. Basic functions are available as below:

  • Authorisation – Performs an authorization for a Merchant in order to access the Apexx Core system.
  • Hosted Payment Request– This is the main method typically performed by various ecommerce and gateway systems to connect with various payment gateways/ acquirers or to jump to the hosted payment page of the payment gateways / acquirers.
  • Upcoming releases of Apexx Core will include the capability for integration with POS terminals
  • Speak to your integration contact when you are ready for sandbox URL’s and test accounts, you will need to confirm which of our supported payment partners you wish to connect with. Or email tech@apexxfintech.com, +44 7482 347732

 

Authorisation


APEXX CORE back office allows the creation of Merchants with multiple supported Payment Gateways and Acquirers. In order to configure unique merchants, we utilise Customer Name, Merchant ID (Auto Generated) and Secret Word.

Once a Merchant is ready, APEXX CORE will provide these details to each specific Merchant. Every Payment Request will require an Authentication Token in order to make a payment request. Following are the details for generating tokens.

API Endpoint

Method

Content Type

URL

POST

application/json

/generateAccessToken

Request Parameter Details

#

Field Name

Apexx Core Parameter Name

Data Type

Mandatory

Field Length

Validation

Description

1

Merchant ID

merchantId

Integer

M

4

Numeric Only

Auto Generated Merchant ID in APEXX CORE
System

2

Merchant Name

merchantName

String

M

64

Alphabets and space

Name of the Merchant

3

Secret Word

secretWord

String

M

32

 

Secret Word of the

Merchant

Response

Status

Response

200

Success Response:

{

"errorMessage": "",

"accessTokenaizer": {

"id": "fc30bce4-494b-41b6-a0ba-649496324769",

"merchantId": 1,

"accessToken": "vr1Tz0j6Jbk1Yvj0iAMwONFPf0UyUxne",

"isActive": true,

"tokenRequestedDate": "16/Aug/2017 00:16:50",

"tokenExpireDate": "14/Nov/2017 00:16:50",

"requestIp": "103.240.34.226"

},

"status": "SUCCESS"

}

On Failure : (If Merchant ID is missing)

{

"errorMessage": [

"Merchant ID is not specified. Please pass the Merchant ID."

],

"status": "FAILED"

}

On Failure : (If Merchant Name is missing)

{

"errorMessage": [

"Merchant Name is not specified. Please pass the Merchant Name."

],

“authCode”:”i0943Is7it1too874h”,

"status": "FAILED"

}

On Failure : (If Secret Word is missing)

{

"errorMessage": [

"Secret Word is not specified. Please pass the Secret Word."

],

"status": "FAILED"

}

 

Hosted Payment Request

All Authorised merchant systems (which have received an accessToken in the above step) can make a request for a Hosted Payment page from their configured payment gateways / acquirers. Redirection to Payment Gateways / acquirers based on Merchant Configuration and the Apexx CORE Rules Engine only.

Basic setup facilitates a manually adjusted sequence-based Payment Gateway selection from the configured Payment Gateways / acquirers of the Merchant.

Automated rules bespoke per client are also available to enable switching on any criteria required.

New gateways, acquirers and ecommerce systems are constantly being integrated – please ask if you need a particular one that we may add for you or that may be in progress.

Following are the details of a standard payment request. Every Payment Gateway has some required fields. Please refer to specific payment gateways / acquirers below for information about required fields for that gateway / acquirer.

API Endpoint

Method

URL

POST

/payment

Request Parameter Details

#

Field Name

Apexx Core Parameter Name

Data Type

Mandatory

Field Length

Validation

Description

1

Merchant ID

merchant_id

Integer

M

<=3

Numeric Only

Valid Merchant Id from Apexx Core

2

Access Token

accessToken

String

M

<=32

Alpha-numeric , space and some special character(_/+.-)

Valid Access Token from Apexx Core

3

Transaction ID

transactions

String

M

<=13

Alpha-numeric

Unique value for each transaction

4

Login ID

loginId

Integer

M

<=3

Numeric Only

Valid Login Id from Apexx Core same as Merchant Id

5

Customer ID

customerId

Integer

M

<=3

Numeric Only

Valid Customer Id from Apexx Core same as Merchant Id

6

Invoice Number/ Order ID

invoiceNumber

String

M

<=16

Alpha-numeric, space and some special character(_-)

Unique identification number for each transaction.

7

Product ID

productId

String

M

<=16

Alpha-numeric, space and some special character(_-)

Unique identification parameter for each product.

8

Description

description

String

M

<=255

Alphabets, space and some special character (,.-)

Sample description for order purchase that is done.

9

Amount

amount

Double

M

<=9

Numeric only

Valid amount in ##.# , ##.## or ##.### format and same as (quantity * priceOrderItem).

For example, amount values like 23.5, 23.57 and 23.789 etc. – that is upto 3 decimal places is allowed.

10

Currency

currency

String

M

3

Capital Alphabets

Standard currency names are supported. (such as GBP, EUR etc.)

11

Name

0.name

String

M

<=32

Alphabets and Space

Product name which end user wants to buy

12

Quantity

0.quantity

Integer

M

<=3

Numeric Only

Proper number of product one wants to buy.

13

Price

0.price

Double

M

<=9

Numeric Only

Valid amount in ##.## or ##.### format

14

Currency

0.currency

String

M

3

Capital alphabets

Standard currency names are supported. (such as GBP, EUR etc.)

15

Description

0.description

String

M

<=255

Alphabets, space and some special characters (,.-)

Sample description for order items.

16

Supplier ID

supplierID

String

M

<=16

Numeric Value and some special characters(,-)

Unique value for each supplier who supplies product.

17

Workflow Pickup Time

minuteForNextWorkFLow

Integer

O

<=3

Numeric Only

Time after that pickup new workflow

18

Supplier Amount Details

supplierAmount

String

M

<=64

Alpha-numeric, new line and some special characters (,.)

every supplier specify in the format - Fixed Amount, Percentage, Per Quantity

19

First Name

firstName

String

M

<=32

Alpha-numeric, space and some special characters (_-/+.)

End user valid First Name

20

Last Name

lastName

String

M

<=32

Alpha-numeric, space and some special characters (_-/+.)

End user valid Last Name

21

Full Name

fullName

String

M

<=64

Alpha-numeric, space and some special characters (_-/+.)

End user valid Full Name

22

Company Name

companyName

String

M

<=128

Alphabets, space and some special characters (,-.)

End user Company Name

23

Address Line 1

address1

String

M

<=64

Alpha-numeric, space and some special characters ([]()_-\|:,./)

End user Address

24

Address Line 2

address2

String

M

<=64

Alpha-numeric, space and some special characters ([]()_-\|:,./)

End user Address

25

City

city

String

M

<=64

Alphabets, space and some special characters (,.-+)

End user City

26

State

state

String

M

<=32

Alphabets, space and some special characters (,.-+)

End user State

27

Country

country

String

M

2

International 2 alphabets country code

End user Country

28

Postal Code/ ZIP Code

postal

String

M

<=16

Alpha-numeric, space and some special characters (._-+/)

End user Postal Code

29

Mobile Number

mobileNumber

Integer

M

>=10 & <=15

Numeric, space and some special characters(+()-)

End user’s valid Mobile Number

30

Email ID

emailId

String

M

<=128

Valid Email Address like abc.mno@xyz.com

End user Valid email Id

31

Success URL

successUrl

String

M

-

Valid values like. http://www.abc.co.in?ref=123

Redirects to this URL whenever any successful response is obtained from the Payment gateway.

32

Failure URL

failureUrl

String

M

-

Valid values like. http://www.abc.co.in?ref=123

Redirects to this URL whenever any failure response is obtained from the Payment gateway.

33

Notification URL

notificationUrl

String

M

-

Valid values like. http://www.abc.co.in?ref=123

Redirects to this URL whenever any status notification needs to be sent back to the system.

34

Name

productName

String

M

<=32

Alphabets and space

Product name which end user wants to buy.

35

Sku

sku

String

M

,=16

Alpha-numeric and Space

Identification code for product

36

Quantity

Quantity

Integer

M

<=3

Numeric only

Proper number of product one wants to buy.

37

Price

priceOrderItem

Double

M

<=7

Numeric only

Valid price in format ##.##

38

Item Tax

itemTax

Double

M

<=7

Numeric only

Valid Item Tax in format ##.##

Response

Status

Response

200

It will redirect to the respective Hosted Payment Gateway page.

 

Success Response Parameter Details

No.

Field Description

Parameter Name

Data Type

Description

1.

Amount

amount

Double

This is the amount of the transaction or payment. E.g., 999 would be $9.99

2.

Currency Code

currencyCode

String

The currency in which the transaction was done.

3.

Gateway Transaction ID

gatewayTransactionId

String

The transaction ID received in HPP Payment response from Gateway. Identifies the transaction at Gateway Level. This is the transaction ID against which the Payment has been requested.

4.

Core Transaction ID

coreTransactionId

Integer

The Transaction ID of CORE Application. Identifies the transaction at CORE Level.

5.

Status

status

String

This is the transaction type. It will be set to: REDIRECTED once the User has been redirected. It will be set to: SUCCESS once the Payment is completely done
It will be set to: FAILED, if the Payment process is failed or to DECLINED, if the Payment gets declined from Paysafe’s end.


* Read more for the entire HPP Payment process and also for the Status values

6.

Merchant Reference Number

merchantRefNum

Integer

This is the merchant transaction ID assigned in the original order request, for reference purposes.

7.

Action

action

String

The type of operation or action performed. For Payments, it will be set to “HPP_PAYMENT”

 

NOTE that the Response will come in a Query String format for HPP Payments

 

Payment Response

Status

Response

REDIRECTED

When the Payments Request comes for the First Time to CORE

merchantRefNum - 1518177311443

gatewayTransactionId - 27LCSL527716R1F1LI

coreTransactionId - 106

amount - 2.0

status - REDIRECTED

currencyCode - GBP

action - HPP_PAYMENT

SUCCESS

Once the Payment is fully settled & completed, the user is notified with the below Response on the Notification URL that is provided:

merchantRefNum - 1518177311443

gatewayTransactionId - 27LCSL527716R1F1LI

coreTransactionId - 106

amount - 2.0

status - SUCCESS

currencyCode - GBP

action - HPP_PAYMENT

 

 

Payment Process with Paysafe

 

How it works and changes in the values for ‘Status’ fields:

Please note that all the values for Status fields are now in UPPERCASE.

Below is the full description for each of the fields:

There are total four values for the status fields displayed in CORE:

  1. REDIRECTED - The User/Customer has been Redirected to the HPP Page. It will be the same when some error occurs on the Paysafe HPP Page itself)
  2. SUCCESS - The Payment was completed successfully 
  3. FAILED - The Payment got Failed.
  4. DECLINED – The Payment got Declined.


If the Status is set to 'REDIRECTED', that means the User has just been Redirected by CORE. It is not completed fully, as Paysafe sends a Postback response after a few minutes (probably, after 10 minutes) once HPP Payment is done. At that time, funds are just Captured (AND NOT SETTLED). Settlement of the funds is done after 30 minutes (Paysafe have a batch processing mechanism of their transactions).

So, the REDIRECTED status is just one kind of acknowledgement to the user. So meanwhile, when one checks in the back-office, the status of the Transaction would be like 

====================================================

Authorisation: Completed (which means Authorisation is fully done)

Settlements: Pending

====================================================

After 30 minutes (once batch job is run), the transaction status for the same transaction ID in the Back-office would be like

==================================================================

Authorisation: Completed

Settlements: Completed (which means now the Payment is fully done/successfully completed)

==================================================================

Once the Postback is received from Paysafe's end to CORE, the status is then updated to 'SUCCESS' (on CORE's side). So, one needs to check after a few minutes for the transaction status. Once the Transaction status is set to SUCCESS in CORE, that means the Payment is successfully completed from Paysafe's end.

Here, again the 3rd Party/End-user will be notified by the Notification URL passed at the time of Refund request.

Please note that some changes might need to be done, as previously the Payments response was notified on the Success URL, but now it is sent on the Notification URL that is passed.

With this Notification URL, response will be sent to the end user in a Query String (Key-value pairs) conveying the actual status of the operation performed.

We are going to send the below set of Parameters as a part of the Callback, whether the Transaction status was SUCCESS or DECLINED

  1. status - Status of the Transaction, whether it was SUCCESS or DECLINED
  2. gatewayTransactionId - Transaction ID of the respective Payment Gateway's Transaction ID
  3. coreTransactionId - Transaction ID of Apexx Core system
  4. amount - Amount of the Transaction
  5. merchantRefNum - Unique value sent for every Order Request
  6. currencyCode - Currency in which the Transaction occurred.
  7. action - Action of the Transaction which could be 'HPP_PAYMENT' or 'REFUND'. Basically, the type of API Operation.

 

REFUND API Details

In order to process a Refund, against a Payment done, below are the API Details:

Request data would be sent as a Form Data (Query String) (Content Type - multipart/form-data)

Response Data would be sent as a JSON (Accept Type - application/json)

Refund API Endpoint

Method

Accept Type

URL

POST

application/json

/paysafeOrderRefundController

Request Parameter Details

No.

Field Name

Parameter Name

Area

Data Type

Mandatory?

Description

1.

Gateway Transaction ID

gatewayTransactionId

Query String

Alpha-numeric

Yes

Transaction ID received from the Gateway at the time of successful payment.

2.

Core Transaction ID

coreTransactionId

Query String

Integer

Yes

Transaction ID returned by CORE application.

3.

Notification URL

notificationUrl

Query String

Text/String

Yes

The notification URL will be used by CORE for sending the notification of the updated Refund status, back to the 3rd Party/Shopping Cart

4.

Merchant ID

merchantId

HTTP Headers

Integer

Yes

Merchant ID from CORE application

5.

Access Token

accessToken

HTTP Headers

Alpha-numeric

Yes

Access Token of the respective merchant for authentication purpose.

Success Response Parameter Details

No.

Field Description

Parameter Name

Data Type

Description

1.

Amount

amount

Double

This is the amount of the transaction that was refunded. E.g., 999 would be $9.99

2.

Currency Code

currencyCode

String

This is the currency in which the transaction was refunded

3.

Gateway Transaction ID

gatewayTransactionId

String

The transaction ID received in Refund response from Gateway. Identifies the transaction at Gateway Level. This is the transaction ID against which the refund has been requested.

4.

Core Transaction ID

coreTransactionId

Integer

The transaction ID of CORE Application. Identifies the transaction at CORE Level.

5.

Status

status

String

This is the transaction type. It will be set to: REFUND_REQUESTED once the Refund is Requested. It will be set to: REFUND_PROCESSED once the Refund is completely done
It will be set to: REFUND_FAILED, if the Refund process is failed from Paysafe’s end.


* Read more at the end of the document for the entire Refund process and also for the Status values

6.

Action

action

String

The type of operation or action performed. For Refund, it will be set to “REFUND_ORDER”

Refund Response

Status

Response

REFUND_REQUESTED

When the Refund Request comes for the First Time to CORE Application and Refund is yet to be done:

{

"amount": "2.00",

"currencyCode": "GBP",

"gatewayTransactionId": "27LCSKOJKT0FJIE1LQ",

"coreTransactionId": "246",

"status": "REFUND_REQUESTED",

"action": "REFUND_ORDER"

}

REFUND_PROCESSED

Once the Refund is fully processed & completed, the user is notified with the below JSON Response on the Notification URL that is provided:

{

"amount": "2.00",

"currencyCode": "GBP",

"gatewayTransactionId": "27LCSKOJKT0FJIE1LQ",

"coreTransactionId": "246",

"status": "REFUND_PROCESSED",

"action": "REFUND_ORDER"

}

REFUND_REJECTED

1. If Merchant ID value is missing, and Merchant ID Parameter is passed:

{

"errorMessage": [

"Merchant ID is not specified. Please pass the Merchant ID."

],

"status": "REFUND_REJECTED"

}

2. If Merchant ID Parameter is not passed in the Header:

{

"errorMessage": [

"Merchant ID parameter is not specified. Please pass the Merchant ID parameter."

],

"status": "REFUND_REJECTED"

}

3. If Access Token is missing:

{

"errorMessage": [

"Access Token is not specified. Please pass a valid Access Token."

],

"status": " REFUND_REJECTED"

}

4. If a valid Merchant ID is passed and an invalid Access Token is passed, or vice-versa:

{

"errorMessage": ["Merchant ID and Access Token passed do not match. Authentication failed. Please try with a valid set of credentials."],

"status": " REFUND_REJECTED"

}

5. If a Refund Request comes for the 2nd time, for a transaction which is already refunded:

{

"errorMessage": [

"You cannot cancel this transaction as it is no longer in a pending state. This transaction has already been refunded."

],

"status": " REFUND_REJECTED"

}

Refund Process with Paysafe

How it works and changes in the values for ‘Status’ fields:

Please note that all the values for Status fields are now in UPPERCASE.

Below is the full description for each of the fields:

There are total four values for the status fields displayed in CORE:

  1. REFUND_REQUESTED - The Refund is Requested
  2. REFUND_PROCESSED - The Refund was completed successfully or processed successfully
  3. REFUND_FAILED - The Refund was failed.
  4. REFUND_REJECTED – The Refund got Rejected due to some errors

If the Status is set to 'REFUND_REQUESTED', that means the Refund has just been Requested by CORE to Paysafe. It is not completed fully, as Paysafe takes 30 minutes in order to settle a payment.

Therefore, it is very necessary to let the Payments be settled first and then try for Refund after 30 minutes.

After the Refund Request is initiated, then only Refund would be allowed otherwise, Refunds will be FAILED and status would be set to REFUND_FAILED

Once the Refund Request is initiated, Credit of the funds is done after 30 minutes (Paysafe have a batch processing mechanism of their transactions).

So meanwhile, when you will check in the back-office, the status of the Transaction would be like 

==================================================================

Settlements: Completed (Payment is done)

Credits: Pending (which means that the Refund amount is still pending and not yet credited in the Back-office Paysafe account)

==================================================================

After 30 minutes (once batch job runs), the Transaction Status for the same Transaction ID would be like:

==================================================================

Settlements: Completed

Credits: Completed (which means now the Refund was completed successfully)

==================================================================

Once the Postback is received from Paysafe's end to CORE, the status is then updated to 'REFUND_PROCESSED' (on CORE's side). So, one needs to check after a few minutes for the transaction status. Once the Transaction status is set to REFUND_PROCESSED in CORE, that means the Refund was fully completed from Paysafe's end.

When you are trying to process a Refund, please wait till 30 minutes i.e. once the Settlement is done (Payment is completed), then only try for a Refund request

Also, when a Refund operation is tried, the actual response obtained from Paysafe also takes 30 minutes to settle/credit in the Back-office Paysafe account (and not the Bank Account)

Here, again the 3rd Party/End-user will be notified by the Notification URL passed at the time of Refund request.

With this Notification URL, response will be sent to the end user in a JSON format conveying the actual status of the operation performed.

“The Bank Accounts are generally credited after 2-3 working days - this is as per Paysafe Tech Team.”

Note: The Settlement Transaction ID and Refund Transaction ID would be different in the Paysafe Back-office

 

DAILY TRANSACTION RECORD API Details

API Endpoint

Method

Content Type

URL

GET

application/json

/getTransactionsByDate

Request Parameter Details

No.

Field Name

Parameter Name

Area

Data Type

Mandatory?

Description

1.

Transaction Date

transactionDate

Query String

Date

Parameter required

Value - Optional

Transaction date of the transaction. (To be passed in in DD-MM-YYYY format only)

NOTE: If the Transaction Date value is not passed, then it will fetch the data/records as per today’s current date.

2.

Transaction Type

transactionType

Query String

String

Parameter required

Value - Optional

Determines the type of the transaction. Acceptable values of this field can be only the below ones:

1. HPP_PAYMENT
2. REFUND

NOTE: If the Transaction type value is not passed, then it will fetch the data/records for both the Transaction types.

3.

Merchant ID

merchantId

HTTP Headers

Integer

Yes

Unique Merchant ID of the merchant.

4.

Access Token

accessToken

HTTP Headers

String

Yes

Access Token of the respective merchant for authentication purpose.

Response Parameter Details

No.

Field Description

Parameter Name

Data Type

Description

1.

Due Date

dueDate

Date

-

2.

Stage

stage

String

-

3.

Currency

currency

String

Currency of the Transaction.

4.

Amount

amount

Integer

Amount of the Transaction.

5.

Unallocated

unallocated

String

-

6.

Merchant Reference

merchantReference

Integer

Unique value passed for every transaction that is done

7.

Client Name

clientName

String

Name of the client to which the transaction was paid.

8.

Card-Holder Name

cardHolderName

String

Name of the Card-Holder from which the transaction was done

9.

Card Type

cardType

String

Type of the Card e.g. VISA, MasterCard etc.

10.

Actions

actions

String

Name of the action/operation performed.

11.

Notes

notes

String

Description obtained for the transaction that is done

12.

Gateway Transaction ID

gatewayTransactionId

String

The transaction ID received in response from Paysafe. Identifies the transaction at Paysafe (Gateway) Level.

13

Core Transaction ID

coreTransactionId

Long

The transaction ID of CORE Application. Identifies the transaction at CORE Level.

14.

Invoice Number

invoiceNumber

String

The invoice number that is sent by any 3rd party with the order request. Identifies the transaction at the any 3rd Party Level.

15.

Transaction Type

transactionType

String

Determines the type of the Transaction. Types can be
1. HPP_PAYMENT and
2. REFUND

Daily Transaction Record API Response

Status

Response

SUCCESS

We have introduced a new field called “transactionType” (see highlighted below) which will indicate which type of Operation it was.

NOTE: The fields that are shown as empty string (like “”) will come like that only as it is dependent on the Payment gateway. If those fields are sent by a payment gateway, then only they will be populated.

{

"dueDate": "",

"stage": "",

"currency": "GBP",

"amount": "17.45",

"unallocated": "",

"merchantReference": "1512455341577",

"clientName": "",

"cardHolderName": "",

"cardType": "",

"actions": "",

"notes": "",

"gatewayTransactionId": "27LCSIU4RZ7PG681LM",

"coreTransactionId": 175,

"invoiceNumber": "705000114",

"transactionType": "HPP_PAYMENT"

}

FAILED

1. If Merchant ID value is missing, and Merchant ID Parameter is passed:

{

"errorMessage": [

"Merchant ID is not specified. Please pass the Merchant ID."

],

"status": "FAILED"

}

2. If Merchant ID Parameter is not passed in the Header:

{

"errorMessage": [

"Merchant ID parameter is not specified. Please pass the Merchant ID parameter."

],

"status": "FAILED"

}

3. If Access Token is missing

{

"errorMessage": [

"Access Token is not specified. Please pass a valid Access Token."

],

"status": "fail"

}

4. If a valid Merchant ID is passed and an invalid Access Token is passed, or vice-versa:

{

"errorMessage": ["Merchant ID and Access Token passed do not match. Authentication failed. Please try with a valid set of credentials."],

"status": "fail"

}

5. If a Future Transaction Date is entered:

{

"errorMessage": ["Transaction Date must be a past date. Please enter a past date in proper format (DD-MM-YYYY) only in"],

"status": "fail"

}

Changes in Transaction Status Values

We have now changed the values for Transaction Status in Apexx Core in order to provide a more robust support for the tracking of a particular Transaction. It is to be noted that we changed the Transaction Status values for both types of requests:

  1. HPP Payments
  2. Refund

HPP Payments

Total 4 values would be there for Transaction Status for HPP Payments Scenario. They are:

SUCCESS - When Paysafe have authorised a transaction

FAILED - When either we (APEXX) haven't been able to redirect to Paysafe or have not got any callback from them

REDIRECTED - When APEXX have sent the customer to paysafe

DECLINED - When Paysafe have not authorised a transaction. One that has been sent for Authorisation to the issuer but not achieved it.

  1. GCEN Request -> CORE
  2. If it is a valid Order Request, it will be redirected to Paysafe, then Transaction status will be set to REDIRECTED. This suggests that the user has been Redirected to Paysafe HPP Page.
  3. If the Order Request received has Invalid values, then status will be FAILED
  4. It remains at REDIRECTED until we get the call-back from Paysafe.
  5. Paysafe -> CORE
  6. If we do not get the call-back from Paysafe after 2 hours, then we update the Transaction status to FAILED.
  7. CORE -> GCEN
  8. The same status would then be passed on to GCEN in their Return URL/Callback URL.

Refund

Total 4 values would be there for Transaction Status for Refund Scenario. They are:

  1. REFUND_REQUESTED - When the Customer sends a Refund Request to APEXX CORE
  2. REFUND_PROCESSED - When Paysafe have Refunded a Transaction
  3. REFUND_FAILED - When Refund failed from Paysafe’s End.
  4. REFUND_REJECTED - If invalid data comes in the Refund request, or if user tries do a refund for the 2nd time or if some system error occurs from APEXX’s side