Class: PaysecureApiDocumentationLive::ApIsApi

#cancel ⇒ `ApiResponse`

Cancels an in-progress or completed purchase transaction, preventing further processing or reversing the authorization hold. Use this endpoint to void a transaction that has not yet been settled to the merchant's account. When to use:

Post-creation cancellation: Cancel a purchase immediately after it has been created via the Purchase API, before the customer completes the payment flow.
Pre-redirect cancellation: Cancel a transaction after completing the server-to-server (S2S) call but before redirecting the cardholder to the callbackURL. This is useful when your backend validation logic determines the transaction should not proceed (e.g., inventory check failure, fraud flag, duplicate order detection).

Purchase ID is mandatory for this API.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 371

def cancel
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/64bff556f63e36669499e9d3/cancel',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success2.method(:from_hash))
                .is_api_response(true)
                .local_error('400',
                             'Bad Request',
                             Error1Exception))
    .execute
end

#cancel1 ⇒ `ApiResponse`

Use this endpoint to cancel an authorised payment before it has been captured. Voiding releases the held funds back to the customer immediately.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2955

def cancel1
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases/69ca76dbace4fa4413db928c/cancel',
                                 Server::SERVER_3))
    .response(new_response_handler
                .is_response_void(true)
                .is_api_response(true)
                .local_error('405',
                             'Method Not Allowed',
                             CancelException))
    .execute
end

#capture(body) ⇒ `ApiResponse`

After a successful pre-authorisation, use this endpoint to capture (settle) the held funds. You may capture the full authorised amount or a partial amount. here

Parameters:

body (CaptureRequest) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2933

def capture(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases/69cd26b053d7b783ebf6b6e9/capture',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .is_response_void(true)
                .is_api_response(true)
                .local_error('500',
                             'Internal Server Error',
                             CaptureException))
    .execute
end

#check_white_list(accept, body) ⇒ `ApiResponse`

Overview

Paysecure supports the concept of whitelisted cards. The merchant can send PaySecure a list of cards that are to be whitelisted. Once whitelisted, only whitelisted cards are allowed to be transacted for that merchant. The merchant can check the individual card status with this API by giving the email and card numbers of the customers.

Mandatory Parameters (in body)

| Parameters | | --- | | email | | card_num |

Other parameters:

| Parameters | | --- | | signup_date | | deposit_date | | number_of_deposits |

Response Examples

In the response examples, you can observe both instances of verifying whether a card exists in a merchant's whitelist, one for an existing card and another for a non-existing card. description here

Parameters:

accept (String) —
Required parameter: TODO: type description here
body (CheckWhiteListRequest) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 413

def check_white_list(accept,
                     body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/checkWhiteList',
                                 Server::SERVER_3)
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json; charset=utf-8', key: 'content-type'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(CheckWhiteListDoesnTExists.method(:from_hash))
                .is_api_response(true))
    .execute
end

#create_customer(brand_id, body) ⇒ `ApiResponse`

OVERIEW The createCustomer API allows merchants to create a customer profile on Paysecure when a user visits their website, facilitating a seamless payment experience by pre-filling the customer's details, on the Paysecure Cashier. The API takes in customer information and returns a unique customerID that can be passed in purchase payload, eliminating the need for customers to manually enter their details during transactions.

Parameter	Type	Required	Description	Example
merchantCustomerId	String	Yes	unique customer ID provided by
merchant. This can be email, mobile or an alphanumeric string

User Flow

Customer visits merchant's website: The customer selects the product or service and proceeds to checkout page.
Merchant calls the createCustomer API: The merchant sends a POST request to the Paysecure API with the customer's details.
Customer ID generation: Paysecure processes the request and generates a unique customerId which is returned in the response.
Payment Process: The merchant uses the customerId for subsequent session creation, ensuring the customer doesn’t need to re-enter their details for future payments.

Benefits

Seamless user experience: The customer does not have to enter their details manually for every purchase.
Faster Checkout: The merchant can use the customerId for faster payment processing.
Data Security: Customer details are stored securely and can be reused across transactions, reducing the chances of errors.

Implementing createCustomer on merchant site:

The createCustomer can be implemented on merchant site in one of two ways, depending on merchant’s integration flow: At Checkout: When a customer initiates the checkout process, your system should invoke the createCustomer API, before actually starting the session.

Call createCustomer: This API call generates a unique customer ID.
Use of Customer ID: Pass the returned customer ID in Session API, when creating a payment session.

Upon Customer Login: Alternatively, merchants may choose to call createCustomer at the time of customer login on their site.

Persistent Customer Profiles: This approach can help build or maintain a persistent customer profile, ensuring the customer ID is available for any subsequent payment sessions without needing to call createCustomer again.
Integration Flexibility: This is useful for merchants who want to initialize customer data early in the customer journey rather than during checkout.

The method you choose depends on your business requirements and how your system is architected. Regardless of when you call it, the resulting customer ID must be passed to the createSession API to initiate a payment session. description here

Parameters:

brand_id (String) —
Required parameter: TODO: type description here
body (CreateCustomerRequest1) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1781

def create_customer(brand_id,
                    body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/customer',
                                 Server::SERVER_3)
               .header_param(new_parameter(brand_id, key: 'BrandId')
                              .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success19.method(:from_hash))
                .is_api_response(true))
    .execute
end

#create_purchase_cit(body) ⇒ `ApiResponse`

OVERIEW The create Purchase API is designed to initiate a payment for a merchant who doesn't want to use Paysecure's cashier and wants to keep everything S2S. The merchant doesn't need to create a customer in this case and directly needs to call the purchase API and then call the S2S API after that.

Additional parameters for this usecase:

Parameter	Notes
payment_type	Mandatory. To be passed as "mandate".
paymentMethod	Mandatory. Example: MASTER, VISA
brand_id	Mandatory. Your brand id.
mandate	Mandatory. This object is mandatory for mandate flow
mandate.mandate_max_amount	Conditional. Mandatory when
amount_variability is "Variable". Maximum amount for a mandate.
mandate.amount_variability	Optional Specifies whether the amount

is fixed or variable for each recurrence.

Possible values: Fixed or Variable | | mandate.start_date | Optional
Specifies the time when the mandate will start. | | mandate.end_date | Optional
Specifies the time when the mandate will end.
(If not passed then indefinite) | | mandate.frequency | Mandatory
Defines the frequency of mandate execution, how often a customer should be charged.

Possible Values:
ONETIME: This is for a one-time mandate. The customer provides authorisation to debit their account a single time for a specific amount.

DAILY: Recurring mandate. The customer provides authorisation to debit their account daily for a specific amount.

WEEKLY: Recurring mandate. Authorisation given by a customer to debit their account weekly once for a specified amount.

FORTNIGHTLY: Recurring mandate. The customer provides authorisation to debit their account fortnightly for a specific amount.

MONTHLY: Recurring mandate. The customer provides authorisation to debit their account monthly for a specific amount.

BIMONTHLY: Recurring mandate. The customer provides authorisation to debit their account bimonthly for a specific amount.

QUARTERLY: Recurring mandate. The customer provides authorisation to debit their account quarterly for a specific amount.

HALFYEARLY: Recurring mandate. The customer provides authorisation to debit their account once in every 6 months for a specific amount.

YEARLY: Recurring mandate. The customer provides authorisation to debit their account once a year for a specific amount.

ASPRESENTED: For cases where the scheduling is handled by the merchant. The customer provides authorization to debit their account whenever there is an execution request. | | mandate.rule | Optional.
Indicates the recurrence rule of the mandate. This rule is not required for onetime, daily, and aspresented recurrence patterns.
Possible values: on/before/after
By Default: on | | mandate.value | Conditional.
The recurrence Value of the mandate.
It is not required for ONETIME, DAILY and ASPRESENTED frequencies.

Possible values:
For WEEKLY: The value should be 1-Monday to 7-Sunday.
For MONTHLY, BIMONTHLY, QUARTERLY, HALFYEARLY or YEARLY: The value should be between 1 to 30/31 days.

By Default: The value will be treated as 1. | description here

Parameters:

body (CreatePurchaseCitRequest) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2016

def create_purchase_cit(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .is_response_void(true)
                .is_api_response(true)
                .local_error('401',
                             'Unauthorized',
                             Success33Exception))
    .execute
end

#create_purchase_mit(accept, body) ⇒ `ApiResponse`

After the successful Mandate registration, Merchant will receive a mandate_id from Paysecure that should be stored against a customer at their end. If the merchant handles their own scheduling, then for the subsequent transactions, the merchant is supposed to pass a combination of customer_id and mandate_id to do a debit. This API will perform a transaction with a PSP based on the mandate_id passed in the request. If Paysecure handles the scheduling for the merchant on their behalf, then this API is not for them. The MIT transactions will be handled by Paysecure from our side. Note: Recurring payments should only be done if the mandate registration has been successful and the mandate is ACTIVE. description here

Parameters:

accept (String) —
Required parameter: TODO: type description here
body (CreatePurchaseMitRequest) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2180

def create_purchase_mit(accept,
                        body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success38.method(:from_hash))
                .is_api_response(true))
    .execute
end

#create_session_cit(brand_id, body) ⇒ `ApiResponse`

OVERIEW The createSession API is designed to initiate a payment session for a customer after their profile has been created via the createCustomer API. The session is automatically generated at the backend on the merchant’s checkout URL. This session allows the customer to continue with their transaction without having to manually interact with the session URL, and ensures the session remains active until the payment is completed or the session expires. This API improves the user experience by reducing transaction failures and enhancing the overall payment process, thus reducing transaction churn rates.

Mandatory Parameters

Parameter	Type	Description	Example
customerId	String	The unique ID of the customer (generated from
createCustomer).	6731a609b6bb5a43ad66c4a6

To register a mandate, pass mandate related parameters in the Create Session API to create a mandate registration purchase. Post transaction completion, use Get Status API and Webhooks to capture mandate registration details.

Additional parameters for this usecase:

Parameter	Notes
payment_type	Mandatory. To be passed as "mandate".
mandate	Mandatory. This object is mandatory for mandate flow
mandate.mandate_max_amount	Optional Maximum amount for a mandate.

| | mandate.amount_variability | Optional
Specifies whether the amount is fixed or variable for each recurrence.

Possible values: Fixed or Variable | | mandate.start_date | Mandatory
Specifies the time when the mandate will start. | | mandate.end_date | Mandatory
Specifies the time when the mandate will end. | | mandate.frequency | Mandatory
Defines the frequency of mandate execution, how often a customer should be charged.

Possible Values:
ONETIME: This is for a one-time mandate. The customer provides authorisation to debit their account a single time for a specific amount.

DAILY: Recurring mandate. The customer provides authorisation to debit their account daily for a specific amount.

WEEKLY: Recurring mandate. Authorisation given by a customer to debit their account weekly once for a specified amount.

FORTNIGHTLY: Recurring mandate. The customer provides authorisation to debit their account fortnightly for a specific amount.

MONTHLY: Recurring mandate. The customer provides authorisation to debit their account monthly for a specific amount.

BIMONTHLY: Recurring mandate. The customer provides authorisation to debit their account bimonthly for a specific amount.

QUARTERLY: Recurring mandate. The customer provides authorisation to debit their account quarterly for a specific amount.

HALFYEARLY: Recurring mandate. The customer provides authorisation to debit their account once in every 6 months for a specific amount.

YEARLY: Recurring mandate. The customer provides authorisation to debit their account once a year for a specific amount.

ASPRESENTED: For cases where the scheduling is handled by the merchant. The customer provides authorization to debit their account whenever there is an execution request. | | mandate.rule | Optional.
Indicates the recurrence rule of the mandate. This rule is not required for onetime, daily, and aspresented recurrence patterns.
Possible values: on/before/after
By Default: on | | mandate.value | Conditional.
The recurrence Value of the mandate.
It is not required for ONETIME, DAILY and ASPRESENTED frequencies.

Possible values:
For WEEKLY: The value should be 1-Monday to 7-Sunday.
For MONTHLY, BIMONTHLY, QUARTERLY, HALFYEARLY or YEARLY: The value should be between 1 to 30/31 days.

By Default: The value will be treated as 1. |

Usage Flow

Customer completes the createCustomer API: Once the customer is created via the createCustomer API, the merchant proceeds to call the createSession API to generate a session.
Merchant sends createSession request: The merchant sends a POST request to the createSession API with the customer’s customerId and the merchant’s brandId.
Session created automatically on the checkout URL: PaySecure creates the session and associates it with the merchant’s checkout page. This session remains active on the backend, allowing the customer to continue the payment process without interruption.
Customer proceeds to checkout: The customer is redirected to the checkout page as part of the merchant's payment flow, where the session is automatically validated. The session remains active for a set period, allowing the customer to complete the payment without needing to manually interact with the session URL.
Session Expiry: The session expires after the set expiration time (expiryOn), ensuring the payment process is completed within the defined window. Default is 15 mins from the creation time.

Benefits

Seamless Checkout: The session URL is automatically generated and active at the backend, ensuring a smoother and uninterrupted customer experience.
Reduced Transaction Failures: By ensuring the session remains active during the payment process, the chances of transaction failures due to session timeouts are minimized.
Improved User Experience: The customer does not need to click on a session URL or navigate away from the page, leading to faster and more secure payment processing. description here

Parameters:

brand_id (String) —
Required parameter: TODO: type description here
body (CreateSessionCitRequest) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1938

def create_session_cit(brand_id,
                       body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/createSession',
                                 Server::SERVER_3)
               .header_param(new_parameter(brand_id, key: 'BrandId')
                              .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success32.method(:from_hash))
                .is_api_response(true))
    .execute
end

#delete_token(token_reference) ⇒ `ApiResponse`

Delete Token

Permanently delete a saved card and deactivate the associated network token. This action is irreversible.

Path Parameters

Parameter	Type	Required	Description
`token_reference`	string	Yes	The `token_reference` of the saved
card to delete. Obtained from the List Saved Cards API.

Important Notes

Deleting a token is permanent. The token_reference can no longer be used for payments.
The associated network token is deactivated with the card network.
If the customer wants to pay with this card again, they will need to re-enter their card details.

When to Delete

Customer explicitly requests removal of their saved card.
GDPR or data retention compliance when a customer closes their account.
Consider implementing a "Remove Card" option in your account management UI. here

Parameters:

token_reference (String) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2584

def delete_token(token_reference)
  @api_call
    .request(new_request_builder(HttpMethodEnum::DELETE,
                                 '/api/v1/tokens/v1/deleteToken/{token_reference}',
                                 Server::SERVER_3)
               .template_param(new_parameter(token_reference, key: 'token_reference')
                                .is_required(true)
                                .should_encode(true))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success49.method(:from_hash))
                .is_api_response(true)
                .local_error('400',
                             'Bad Request',
                             FailureException))
    .execute
end

#get_customer(brand_id, accept) ⇒ `ApiResponse`

This endpoint makes an HTTP GET request to retrieve customer information from the Paysecure API.

Request

The request does not include any query parameters, but it uses a raw request body with the following parameter "merchantCustomerId", which will be the customer id on the merchant's side.

Response

The response of this request can be documented as a JSON schema.

Parameters:

brand_id (String) —
Required parameter: TODO: type description here
accept (String) —
Required parameter: TODO: type description here

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1812

def get_customer(brand_id,
                 accept)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/customer',
                                 Server::SERVER_2)
               .header_param(new_parameter(brand_id, key: 'BrandId')
                              .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true)))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success19.method(:from_hash))
                .is_api_response(true))
    .execute
end

#get_mandate(accept, brand_id) ⇒ `ApiResponse`

This endpoint will be used to get all the details of a particular mandate. You can search for a particular mandate id or for a particular session id.

Response parameters:

totalDeductedAmount This is the total amount which is deducted from the user's account.
recurringMandateIds This object returns a list of all the MIT transactions done for the respective mandate.
nextMandateDate This is the date when the next recurring payment will happen.

Parameters:

accept (String) —
Required parameter: TODO: type description here
brand_id (String) —
Required parameter: TODO: type description here

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2144

def get_mandate(accept,
                brand_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/mandate/{mandate_id or session_id}',
                                 Server::SERVER_3)
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true))
               .header_param(new_parameter(brand_id, key: 'BrandId')
                              .is_required(true)))
    .response(new_response_handler
                .is_response_void(true)
                .is_api_response(true)
                .local_error('500',
                             'Internal Server Error',
                             Success36Exception))
    .execute
end

#get_status ⇒ `ApiResponse`

This API tells you about all the details of a purchase, including its history

Mandatory

you need to pass the PurchaseID in the API URL

Possible Value of Status

Status	Notes
created	When Purchase order is created.
paid	Transaction Successful
payment_in_process	Payment is under Processing
chargeback	Payment is chargeback state
refund_in_process	Refund is under Processing.
expired	Purchase has Expired.
overdue	Purchase is Overdued.
cancelled	Purchase is cancelled.
error	Transaction has Failed.
refunded	Payment is refunded

Response Examples

In the response examples you can see instances of both Paid and Error Status purchases.

Error Details

If there are any issues on the Purchase you can get more details from the transaction_data.attempts.error attribute of the response object

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 290

def get_status
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/purchaseid',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PurchasesError.method(:from_hash))
                .is_api_response(true))
    .execute
end

#get_status1(purchase_id) ⇒ `ApiResponse`

This API tells you about all the details of a purchase (PayIn), including its history

Mandatory

you need to pass the PurchaseID in the API URL

Possible Value of Status

Status	Notes
paid	Transaction Successful
payment_in_process	Payment is under Processing
expired	Purchase has Expired.
error	Transaction has Failed.

Response Examples

In the response examples you can see instances of both Paid and Error Status purchases.

Error Details

If there are any issues on the Purchase you can get more details from the transaction_data.attempts.error attribute of the response object

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details. here

Parameters:

purchase_id (String) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1011

def get_status1(purchase_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/{purchaseId}',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .template_param(new_parameter(purchase_id, key: 'purchaseId')
                                .is_required(true)
                                .should_encode(true)))
    .response(new_response_handler
                .deserializer(APIHelper.method(:deserialize_primitive_types))
                .deserialize_into(proc do |response| response&.to_s end)
                .is_api_response(true)
                .is_primitive_response(true))
    .execute
end

#get_status11 ⇒ `ApiResponse`

This API tells you about all the details of a purchase, including its history

Mandatory

you need to pass the PurchaseID in the API URL

Possible Value of Status

Status	Notes
created	When Purchase order is created.
paid	Transaction Successful
payment_in_process	Payment is under Processing
chargeback	Payment is chargeback state
refund_in_process	Refund is under Processing.
expired	Purchase has Expired.
overdue	Purchase is Overdued.
cancelled	Purchase is cancelled.
error	Transaction has Failed.
refunded	Payment is refunded

Response Examples

In the response examples you can see instances of both Paid and Error Status purchases.

Error Details

If there are any issues on the Purchase you can get more details from the transaction_data.attempts.error attribute of the response object

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1650

def get_status11
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/64bff12bf63e36669499e97d',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PurchasesSuccess.method(:from_hash))
                .is_api_response(true))
    .execute
end

#get_status2(purchase_id) ⇒ `ApiResponse`

This API tells you about all the details of a purchase (PayIn), including its history

Mandatory

you need to pass the PurchaseID in the API URL

Possible Value of Status

Status	Notes
paid	Transaction Successful
payment_in_process	Payment is under Processing
expired	Purchase has Expired.
error	Transaction has Failed.

Response Examples

In the response examples you can see instances of both Paid and Error Status purchases.

Error Details

If there are any issues on the Purchase you can get more details from the transaction_data.attempts.error attribute of the response object

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details. here

Parameters:

purchase_id (String) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1251

def get_status2(purchase_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/{purchaseId}',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .template_param(new_parameter(purchase_id, key: 'purchaseId')
                                .is_required(true)
                                .should_encode(true))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PurchaseSuccess4.method(:from_hash))
                .is_api_response(true))
    .execute
end

#get_status3(purchase_id) ⇒ `ApiResponse`

This API tells you about all the details of a purchase (PayIn), including its history

Mandatory

you need to pass the PurchaseID in the API URL

Possible Value of Status

Status	Notes
paid	Transaction Successful
payment_in_process	Payment is under Processing
expired	Purchase has Expired.
error	Transaction has Failed.

Response Examples

In the response examples you can see instances of both Paid and Error Status purchases.

Error Details

If there are any issues on the Purchase you can get more details from the transaction_data.attempts.error attribute of the response object

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details. here

Parameters:

purchase_id (String) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1483

def get_status3(purchase_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/{purchaseId}',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .template_param(new_parameter(purchase_id, key: 'purchaseId')
                                .is_required(true)
                                .should_encode(true))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PurchaseSuccess4.method(:from_hash))
                .is_api_response(true))
    .execute
end

#get_status4(purchase_id) ⇒ `ApiResponse`

This API tells you about all the details of a recurring payment which occurred

Mandatory

you need to pass the PurchaseID in the API URL

Possible Value of Status

Status	Notes
paid	Transaction Successful
expired	Purchase has Expired.
error	Transaction has Failed.

Response Examples

In the response examples you can see instances of both Paid and Error Status purchases.

Error Details

If there are any issues on the Purchase you can get more details from the transaction_data.attempts.error attribute of the response object

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details. here

Parameters:

purchase_id (String) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2344

def get_status4(purchase_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/{purchaseId}',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .template_param(new_parameter(purchase_id, key: 'purchaseId')
                                .is_required(true)
                                .should_encode(true))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success41.method(:from_hash))
                .is_api_response(true))
    .execute
end

#get_status5(purchase_id) ⇒ `ApiResponse`

This API tells you about all the details of a purchase (PayIn), including its history

Mandatory

you need to pass the PurchaseID in the API URL

Possible Value of Status

Status	Notes
paid	Transaction Successful
payment_in_process	Payment is under Processing
expired	Purchase has Expired.
error	Transaction has Failed.

Response Examples

In the response examples you can see instances of both Paid and Error Status purchases.

Error Details

If there are any issues on the Purchase you can get more details from the transaction_data.attempts.error attribute of the response object

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details. here

Parameters:

purchase_id (String) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 803

def get_status5(purchase_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/{purchaseId}',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .template_param(new_parameter(purchase_id, key: 'purchaseId')
                                .is_required(true)
                                .should_encode(true)))
    .response(new_response_handler
                .deserializer(APIHelper.method(:deserialize_primitive_types))
                .deserialize_into(proc do |response| response&.to_s end)
                .is_api_response(true)
                .is_primitive_response(true))
    .execute
end

#list_mandates(customer_id, email, accept, brand_id) ⇒ `ApiResponse`

This endpoint will be used to list all the mandates for a particular customer of a merchant.

Response parameters:

totalDeductedAmount This is the total amount which is deducted from the user's account.
recurringMandateIds This object returns a list of all the MIT transactions done for the respective mandate.
nextMandateDate This is the date when the next recurring payment will happen. here

Parameters:

customer_id (String) —
Required parameter: TODO: type description
email (String) —
Required parameter: TODO: type description here
accept (String) —
Required parameter: TODO: type description here
brand_id (String) —
Required parameter: TODO: type description here

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2293

def list_mandates(customer_id,
                  email,
                  accept,
                  brand_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/mandate',
                                 Server::SERVER_3)
               .query_param(new_parameter(customer_id, key: 'customerId')
                             .is_required(true))
               .query_param(new_parameter(email, key: 'email')
                             .is_required(true))
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true))
               .header_param(new_parameter(brand_id, key: 'BrandId')
                              .is_required(true)))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success40.method(:from_hash))
                .is_api_response(true))
    .execute
end

#list_saved_cards ⇒ `ApiResponse`

List Saved Cards

Retrieve all saved card tokens for a given customer. Returns the last 4 digits of each card and its associated token_reference. Use this API to display saved cards to the customer for selection before initiating a payment via the S2S API.

Query Parameters

Parameter	Type	Required	Description
`customerId`	string	Yes	Unique identifier for the customer. Must

Response Fields

Field	Type	Description
`card_last_four`	string	Last 4 digits of the stored card. Display to
the customer for card selection.
`token_reference`	string	Unique reference for this saved card. Pass

this in the S2S payment request or Delete Token request. Do not display to the customer. |

Notes

The token_reference does not expire. It remains valid as long as the saved card has not been deleted.
Show saved cards to the customer using card_last_four alongside a card brand icon (Visa / Mastercard).
The token_reference should only be stored and used server-side.

Display Tip

Show saved cards using cardlast4 alongside a card brand icon (Visa / Mastercard). The token_reference should only be stored and used server-side.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2395

def list_saved_cards
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/listSavedCards',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success46.method(:from_hash))
                .is_api_response(true)
                .is_response_array(true))
    .execute
end

#pause_mandate(accept, brand_id, body) ⇒ `ApiResponse`

Required for cases where the Paysecure is handling the scheduling of recurring payments. Use this API to pause an ACTIVE mandate.

Additional parameters for this usecase:

Parameter	Notes
command	Mandatory. To be passed as "pause".
mandate_id	Mandatory.
pause_start_date	Optional Date in UNIX EPOCH timestamp (UTC

timezone) format, when the mandate will be paused.
If not passed, Default value will be the current date. | | pause_end_date | Mandatory
Date in UNIX EPOCH timestamp (UTC timezone) format, when the mandate status will be automatically changed to ACTIVE. | Note: For pausing a mandate you need to keep the exact timestamp in mind. If a recurring payment is scheduled between the pause_start_date and pause_end_date then it will not be executed. description here

Parameters:

accept (String) —
Required parameter: TODO: type description here
brand_id (String) —
Required parameter: TODO: type description here
body (PauseMandateRequest) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2253

def pause_mandate(accept,
                  brand_id,
                  body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/mandate',
                                 Server::SERVER_3)
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true))
               .header_param(new_parameter(brand_id, key: 'BrandId')
                              .is_required(true))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json; charset=utf-8', key: 'content-type'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PauseMandate.method(:from_hash))
                .is_api_response(true))
    .execute
end

#pay_out(accept, body) ⇒ `ApiResponse`

Overview

The Original Credit Transaction (OCT), commonly referred to as Push to Card, enables merchants to facilitate near-instantaneous fund transfers directly to a customer’s eligible Visa or Mastercard debit or credit card. Unlike traditional refund processes that can only return funds from a previous purchase, OCT allows for independent disbursements of funds to a cardholder's account. This feature is designed for high-velocity industries that require frictionless, real-time payouts, such as:

Gaming & Betting: Real-time withdrawal of player winnings.
Marketplaces: Payouts to sellers or service providers.
Corporate Disbursements: Instant insurance claims, rebates, or compensation payments.
Merchant Settlements: Faster access to processed funds for sub-merchants.

By utilizing the Paysecure `/payout` API with the `PAYOUT-CARDS` method, you benefit from a unified orchestration layer that handles the complexities of card network routing, ensuring high success rates and global reach while maintaining the same security standards as your standard payment integrations.

Integration Steps

Enable OCT: Ensure "Push to Card" permissions are enabled for your merchant account in the Paysecure Merchant Portal.
Collect Card Details: Collect the recipient's card details securely, or use Paysecure's Cashier to collect the card information on your behalf.
Execute Payout: Call the /payout endpoint with the OCT-specific payout method.
Handle Webhooks: Listen for the paid or failure events to update your internal records.

Mandatory parameters in the request body:

Parameter	Required	Notes
client.email	Yes	The customer's email.
client.phone	Yes	The customer's phone number along with the country
code. Example: +91 9634088651
client.city	Yes	The customer's city.
client.country	Yes	ISO-3166 Country Code. Must be upper case.
Example “SG” (Alpha2)
client.stateCode	Optional	Example “AL”, “XZ”. Must be in upper case.

Parameters:

accept (String) —
Required parameter: TODO: type description here
body (PayOutRequest) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 592

def pay_out(accept,
            body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/payout',
                                 Server::SERVER_3)
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json; charset=utf-8', key: 'content-type'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:deserialize_primitive_types))
                .deserialize_into(proc do |response| response&.to_s end)
                .is_api_response(true)
                .is_primitive_response(true))
    .execute
end

#pay_out1(accept, body) ⇒ `ApiResponse`

Overview

The Original Credit Transaction (OCT), commonly referred to as Push to Card, enables merchants to facilitate near-instantaneous fund transfers directly to a customer’s eligible Visa or Mastercard debit or credit card. Unlike traditional refund processes that can only return funds from a previous purchase, OCT allows for independent disbursements of funds to a cardholder's account. This feature is designed for high-velocity industries that require frictionless, real-time payouts, such as:

Gaming & Betting: Real-time withdrawal of player winnings.
Marketplaces: Payouts to sellers or service providers.
Corporate Disbursements: Instant insurance claims, rebates, or compensation payments.
Merchant Settlements: Faster access to processed funds for sub-merchants.

By utilizing the Paysecure `/payout` API with the `PAYOUT-CARDS` method, you benefit from a unified orchestration layer that handles the complexities of card network routing, ensuring high success rates and global reach while maintaining the same security standards as your standard payment integrations.

Integration Steps

Enable OCT: Ensure "Push to Card" permissions are enabled for your merchant account in the Paysecure Merchant Portal.
Collect Card Details: Use a secure method to collect the recipient's card number and expiry date or can you Paysecure's cashier to do that.
Execute Payout: Call the /payout endpoint with the OCT-specific payout method.
Handle Webhooks: Listen for the paid or failure events to update your internal records.

Mandatory parameters in the request body:

Parameter	Required	Notes
client.email	Yes	The customer's email. Please send it in small
case.
client.phone	Yes	The customer's phone number along with the country
code. Example: +91 9634088651
client.city	Yes	The customer's city.
client.country	Yes	ISO-3166 Country Code. Must be upper case.
Example “SG” (Alpha2)
client.stateCode	Optional	Example “AL”, “XZ”. Must be in upper case.

Parameters:

accept (String) —
Required parameter: TODO: type description here
body (PayOutRequest3) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2683

def pay_out1(accept,
             body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/payout',
                                 Server::SERVER_3)
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json; charset=utf-8', key: 'content-type'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .is_response_void(true)
                .is_api_response(true)
                .local_error('401',
                             'Unauthorized',
                             APIException))
    .execute
end

#payment_methods(brand_id) ⇒ `ApiResponse`

This API gives back the list of Payment methods available for a brand.

Parameters:

brand_id (String) —
Required parameter: TODO: type description here

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 335

def payment_methods(brand_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/payment_methods',
                                 Server::SERVER_3)
               .query_param(new_parameter(brand_id, key: 'brand_id')
                             .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PaymentMethodSuccess.method(:from_hash))
                .is_api_response(true)
                .local_error('401',
                             'Unauthorized',
                             PaymentMethodsErrorException))
    .execute
end

#payment_to_be_initiated_from_client_browser(accept) ⇒ `ApiResponse`

This is the callback URL that is in the response object of the Server-to-Server Call When this URL is called from the end user's browser, the user would be redirected to the success_redirect or failure_redirect URL given by the merchant at the time of create purchase When this URL is called from the end user's browser, if card is 3DS enrolled, the user will be redirect to a verification screen or challenge by the issuing bank and upon successful user verification, the user would be redictected to the success URL given in /purchases API . If for some reason the transactions is unsuccessful, the user will be redirect to failure URL given in /purchases API API .

Parameters:

accept (String) —
Required parameter: TODO: type description here

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 241

def payment_to_be_initiated_from_client_browser(accept)
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/payment/purchaseid',
                                 Server::SERVER_3)
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true)))
    .response(new_response_handler
                .is_response_void(true)
                .is_api_response(true)
                .local_error('400',
                             'Bad Request',
                             PaymentErrorException))
    .execute
end

#purchase(body) ⇒ `ApiResponse`

To Initiate a payment, the very first call to make is /purchases with the required data in the request body. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Mandatory parameters in the request body:

Parameter	Notes
client.email	The customer's email.
client.city	The customer's city.
client.country	ISO-3166 Country Code. Must be upper case. Example “SG”
(Alpha2)
client.stateCode	Example “AL”, “XZ”. Must be in upper case.
Client.street_address	The customer's address.
client.zip_code	The customer's ZIP or postal code. If country=US, zip
format must be NNNNN or NNNNN-NNNN.
purchase.currency	ISO 4217 code for currency you want to send the

transaction in.

Please note, the currency has to be enabled by the account manager for your account. | | purchase.products | An object which contains the list of products which the customer is buying. | | purchase.products.name | The name of the product. | | purchase.products.price | Price in decimal format.
example 1:
EUR 5 , should be sent as 5.00

example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Obtain from Dashboard section of your merchant account login. | | success_redirect | URL to send the user if the transactions is successful. | | pending_redirect | URL to send the user if the transactions is in pending. | | failure_redirect | URL to send the user if the transactions is unsuccessful. |

Essential Optional Parameters

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction. Upon successul create on a Purchase you'd get a "purchaseId" . Use this ID for the next step in Server to server call by calling p/{purchaseId}/?s2s=true .

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL.

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Possible Error Messages

| Error Messages | | --- | | Allowed Limit for this card for particular time period has been consumed | | some Mandatory Parameter are missing | | Invalid format of Date_of_Birth [allowed format: yyyy-mm-dd] | | Invalid Email Format | | Please submit Valid Alpha2 Country Code Ex:(AF,IN) in \"country\" parameter | | Please pass Valid State Code | | Please pass valid street address in \"street_address\" parameter | | Please pass valid city name in \"city\" parameter | | Please pass valid postal Code name in \"zip_code\" parameter | | You are not Allowed for Live Transaction | | Merchant Limit is not set | | Minimum amount is not set for this merchant | | Brand not found ! | | Your charges setting is incomplete .Plese Contact to Administrator. | | Only {currencyCode} currency is allowed. | | Transaction amount must be equal or greater to minimum trans amount | | Invalid_Parameter
You'd usually get it when one or more mandatory parameters are not present in the request. | here

Parameters:

body (PurchaseRequest) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 109

def purchase(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success.method(:from_hash))
                .is_api_response(true))
    .execute
end

#purchase1(body) ⇒ `ApiResponse`

To Initiate a payment, the very first call to make is /purchases with the required data in the request body. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Mandatory parameters in the request body:

Parameter	Notes
client.email	The customer's email.
client.city	The customer's city.
client.country	ISO-3166 Country Code. Must be upper case. Example “SG”
(Alpha2)
client.stateCode	Example “AL”, “XZ”. Must be in upper case.
Client.street_address	The customer's address.
client.zip_code	The customer's ZIP or postal code. If country=US, zip
format must be NNNNN or NNNNN-NNNN.
purchase.currency	ISO 4217 code for currency you want to send the

transaction in.

Please note, the currency has to be enabled by the account manager for your account. | | purchase.products | An object which contains the list of products which the customer is buying. | | purchase.products.name | The name of the product. | | purchase.products.price | Price in decimal format.
example 1:
EUR 5 , should be sent as 5.00

example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Obtain from Dashboard section of your merchant account login. | | success_redirect | URL to send the user if the transactions is successful. | | pending_redirect | URL to send the user if the transactions is in pending. | | failure_redirect | URL to send the user if the transactions is unsuccessful. |

Essential Optional Parameters

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction. Upon successul create on a Purchase you'd get a "purchaseId" . Use this ID for the next step in Server to server call by calling p/{purchaseId}/?s2s=true .

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL.

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Possible Error Messages

| Error Messages | | --- | | Allowed Limit for this card for particular time period has been consumed | | some Mandatory Parameter are missing | | Invalid format of Date_of_Birth [allowed format: yyyy-mm-dd] | | Invalid Email Format | | Please submit Valid Alpha2 Country Code Ex:(AF,IN) in \"country\" parameter | | Please pass Valid State Code | | Please pass valid street address in \"street_address\" parameter | | Please pass valid city name in \"city\" parameter | | Please pass valid postal Code name in \"zip_code\" parameter | | You are not Allowed for Live Transaction | | Merchant Limit is not set | | Minimum amount is not set for this merchant | | Brand not found ! | | Your charges setting is incomplete .Plese Contact to Administrator. | | Only {currencyCode} currency is allowed. | | Transaction amount must be equal or greater to minimum trans amount | | Invalid_Parameter
You'd usually get it when one or more mandatory parameters are not present in the request. | here

Parameters:

body (PurchaseRequest2) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1600

def purchase1(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(OpenBankingEuUk.method(:from_hash))
                .is_api_response(true))
    .execute
end

#purchase2(body) ⇒ `ApiResponse`

Purchase

Initiate a payment transaction. This is the standard Paysecure Purchase API. When a customer completes the purchase on the Paysecure checkout page and opts to save their card, Paysecure provisions a network token in the background and generates a token_reference linked to the customer.

Mandatory Parameters

Parameter	Type	Description
`client.email`	string	Customer's email address. Please send it
in smallcase
`client.city`	string	Customer's city.
`client.country`	string	ISO-3166 Alpha-2 country code, uppercase
(e.g., IN, US, SG).
`client.stateCode`	string	State code, uppercase (e.g., RJ, CA, AL).

Optional Parameters

Parameter	Type	Description
`pending_redirect`	string	URL to redirect when payment is pending.
`success_callback`	string	Server-to-server webhook URL for success.

Key Response Fields

Field	Description
`id`	Unique purchase ID.
`checkout_url`	Redirect customer here to complete payment. Card saving
happens during this step.
`direct_post_url`	URL for S2S payment submission.
`status`	Purchase status. Initially "created".

Network Tokenisation & Card Saving

When the customer completes payment via checkout_url and opts to save their card, Paysecure provisions a network token. The token_reference is then available via the List Saved Cards API. here

Parameters:

body (PurchaseRequest3) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2463

def purchase2(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success47.method(:from_hash))
                .is_api_response(true))
    .execute
end

#purchase3(body) ⇒ `ApiResponse`

Use this endpoint to authorise a payment without capturing it. This places a temporary hold on the customer’s funds for the specified amount. To Initiate a payment, the very first call to make is /purchases with the required data in the request body. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Mandatory parameters in the request body:

Parameter	Notes
client.email	The customer's email.
client.city	The customer's city.
client.country	ISO-3166 Country Code. Must be upper case. Example “SG”
(Alpha2)
client.stateCode	Example “AL”, “XZ”. Must be in upper case.
Client.street_address	The customer's address.
client.zip_code	The customer's ZIP or postal code. If country=US, zip
format must be NNNNN or NNNNN-NNNN.
purchase.currency	ISO 4217 code for currency you want to send the

transaction in.

Please note, the currency has to be enabled by the account manager for your account. | | purchase.products | An object which contains the list of products which the customer is buying. | | purchase.products.name | The name of the product. | | purchase.products.price | Price in decimal format.
example 1:
EUR 5 , should be sent as 5.00

example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Obtain from Dashboard section of your merchant account login. | | success_redirect | URL to send the user if the transactions is successful. | | pending_redirect | URL to send the user if the transactions is in pending. | | failure_redirect | URL to send the user if the transactions is unsuccessful. |

Additional parameters for this usecase:

Parameter	Notes
skip_capture	true

Essential Optional Parameters

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction. Upon successul create on a Purchase you'd get a "purchaseId" . Use this ID for the next step in Server to server call by calling p/{purchaseId}/?s2s=true .

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL.

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Possible Error Messages

| Error Messages | | --- | | Allowed Limit for this card for particular time period has been consumed | | some Mandatory Parameter are missing | | Invalid format of Date_of_Birth [allowed format: yyyy-mm-dd] | | Invalid Email Format | | Please submit Valid Alpha2 Country Code Ex:(AF,IN) in \"country\" parameter | | Please pass Valid State Code | | Please pass valid street address in \"street_address\" parameter | | Please pass valid city name in \"city\" parameter | | Please pass valid postal Code name in \"zip_code\" parameter | | You are not Allowed for Live Transaction | | Merchant Limit is not set | | Minimum amount is not set for this merchant | | Brand not found ! | | Your charges setting is incomplete .Plese Contact to Administrator. | | Only {currencyCode} currency is allowed. | | Transaction amount must be equal or greater to minimum trans amount | | Invalid_Parameter
You'd usually get it when one or more mandatory parameters are not present in the request. | here

Parameters:

body (PurchaseRequest4) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2810

def purchase3(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Purchase73.method(:from_hash))
                .is_api_response(true))
    .execute
end

#purchases(body) ⇒ `ApiResponse`

To Initiate a payment, the very first call to make is /purchases with the required data in the request body. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Parameters in the request body:

Parameter	Notes
client.full_name	Conditional. But Recommended to pass the
complete name of the client. Atleast 2 words recommended.
client.email	Conditional. But Recommended to pass a correct email
id.
paymentMethod	Conditional. Mandatory if you are not using
Paysecure Cashier. Else Non Mandatory. Value: GOOGLEPAY-REDIRECT
purchase.currency	Mandatory. ISO 4217 code for currency you want
to send the transaction in. This should be 'BRL' for PIX.
purchase.products.name	Mandatory.
purchase.products.price	Mandatory. Price in decimal format upto 2

decimals.
example 1:
EUR 5 , should be sent as 5.00
example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Mandatory.
Obtain from Dashboard section of your merchant account login. | | success_redirect | Mandatory.
URL to send the user if the transactions is successful. | | pending_redirect | Mandatory.
URL to send the user if the transactions is in progress state. | | failure_redirect | Mandatory
URL to send the user if the transactions has failed. |

Optional Parameters

expireInMin

This parameter, when passed in the PayIn request, sets the time window within which a customer should make the Interac payment through their bank's app. If a customer doesn't complete the payment within the configured time window, the status of the payment will be marked as 'EXPIRED' in Paysecure. However, in certain cases, a payment made outside of this window could still be successful i.e. customer's account may be debited which would result in inconsistencies among Paysecure's, merchant's and customer's status of the transaction. To avoid such cases it is advised to set the expiry time limit appropriately and advise the customers to make payment within this window. However, if there is an inconsistency between the status at Paysecure and at customer's Bank, the merchant and Paysecure will reconcile the amounts during the settlement.

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction.

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL. here

Parameters:

body (PurchasesRequest6) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 687

def purchases(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:deserialize_primitive_types))
                .deserialize_into(proc do |response| response&.to_s end)
                .is_api_response(true)
                .is_primitive_response(true))
    .execute
end

#purchases1(body) ⇒ `ApiResponse`

To Initiate a payment, the very first call to make is /purchases with the required data in the request body. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Parameters in the request body:

Parameter	Notes
client.full_name	Conditional. But Recommended to pass the
complete name of the client. Atleast 2 words recommended.
client.email	Conditional. But Recommended to pass a correct email
id.
paymentMethod	Conditional. Mandatory if you are not using
Paysecure Cashier. Else Non Mandatory. Value: APPLEPAY-REDIRECT
purchase.currency	Mandatory. ISO 4217 code for currency you want
to send the transaction in. This should be 'BRL' for PIX.
purchase.products.name	Mandatory.
purchase.products.price	Mandatory. Price in decimal format upto 2

decimals.
example 1:
EUR 5 , should be sent as 5.00
example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Mandatory.
Obtain from Dashboard section of your merchant account login. | | success_redirect | Mandatory.
URL to send the user if the transactions is successful. | | pending_redirect | Mandatory.
URL to send the user if the transactions is in progress state. | | failure_redirect | Mandatory
URL to send the user if the transactions has failed. |

Optional Parameters

expireInMin

This parameter, when passed in the PayIn request, sets the time window within which a customer should make the Interac payment through their bank's app. If a customer doesn't complete the payment within the configured time window, the status of the payment will be marked as 'EXPIRED' in Paysecure. However, in certain cases, a payment made outside of this window could still be successful i.e. customer's account may be debited which would result in inconsistencies among Paysecure's, merchant's and customer's status of the transaction. To avoid such cases it is advised to set the expiry time limit appropriately and advise the customers to make payment within this window. However, if there is an inconsistency between the status at Paysecure and at customer's Bank, the merchant and Paysecure will reconcile the amounts during the settlement.

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction.

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL. here

Parameters:

body (PurchasesRequest6) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 895

def purchases1(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:deserialize_primitive_types))
                .deserialize_into(proc do |response| response&.to_s end)
                .is_api_response(true)
                .is_primitive_response(true))
    .execute
end

#purchases_decrypted_flow(body) ⇒ `ApiResponse`

To process a Google Pay transaction, a Purchase must first be created using the /purchases API. The Google Pay token must be included in the request under extraParam.googlepay_param. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Parameters in the request body:

Parameter	Notes
client.full_name	Conditional. But Recommended to pass the
complete name of the client. Atleast 2 words recommended.
client.email	Conditional. But Recommended to pass a correct email
id.
paymentMethod	Conditional. Mandatory if you are not using
Paysecure Cashier. Else Non Mandatory. Value: GOOGLEPAY
purchase.currency	Mandatory. ISO 4217 code for currency you want
to send the transaction in. This should be 'BRL' for PIX.
purchase.products.name	Mandatory.
purchase.products.price	Mandatory. Price in decimal format upto 2

decimals.
example 1:
EUR 5 , should be sent as 5.00
example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Mandatory.
Obtain from Dashboard section of your merchant account login. | | success_redirect | Mandatory.
URL to send the user if the transactions is successful. | | pending_redirect | Mandatory.
URL to send the user if the transactions is in progress state. | | failure_redirect | Mandatory
URL to send the user if the transactions has failed. |

Optional Parameters

expireInMin

This parameter, when passed in the PayIn request, sets the time window within which a customer should make the Interac payment through their bank's app. If a customer doesn't complete the payment within the configured time window, the status of the payment will be marked as 'EXPIRED' in Paysecure. However, in certain cases, a payment made outside of this window could still be successful i.e. customer's account may be debited which would result in inconsistencies among Paysecure's, merchant's and customer's status of the transaction. To avoid such cases it is advised to set the expiry time limit appropriately and advise the customers to make payment within this window. However, if there is an inconsistency between the status at Paysecure and at customer's Bank, the merchant and Paysecure will reconcile the amounts during the settlement.

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction.

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL.

Flow Diagram:

description here

Parameters:

body (PurchasesDecryptedFlowRequest) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1205

def purchases_decrypted_flow(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PurchaseSuccess4.method(:from_hash))
                .is_api_response(true))
    .execute
end

#purchases_decrypted_flow_1(body) ⇒ `ApiResponse`

To process an Apple Pay transaction, a Purchase must be created using the /purchases API. The Apple Pay token must be included under extraParam.applepay_param. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Parameters in the request body:

Parameter	Notes
client.full_name	Conditional. But Recommended to pass the
complete name of the client. Atleast 2 words recommended.
client.email	Conditional. But Recommended to pass a correct email
id.
paymentMethod	Conditional. Mandatory if you are not using
Paysecure Cashier. Else Non Mandatory. Value: APPLEPAY
purchase.currency	Mandatory. ISO 4217 code for currency you want
to send the transaction in. This should be 'BRL' for PIX.
purchase.products.name	Mandatory.
purchase.products.price	Mandatory. Price in decimal format upto 2

decimals.
example 1:
EUR 5 , should be sent as 5.00
example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Mandatory.
Obtain from Dashboard section of your merchant account login. | | success_redirect | Mandatory.
URL to send the user if the transactions is successful. | | pending_redirect | Mandatory.
URL to send the user if the transactions is in progress state. | | failure_redirect | Mandatory
URL to send the user if the transactions has failed. |

Optional Parameters

expireInMin

This parameter, when passed in the PayIn request, sets the time window within which a customer should make the Interac payment through their bank's app. If a customer doesn't complete the payment within the configured time window, the status of the payment will be marked as 'EXPIRED' in Paysecure. However, in certain cases, a payment made outside of this window could still be successful i.e. customer's account may be debited which would result in inconsistencies among Paysecure's, merchant's and customer's status of the transaction. To avoid such cases it is advised to set the expiry time limit appropriately and advise the customers to make payment within this window. However, if there is an inconsistency between the status at Paysecure and at customer's Bank, the merchant and Paysecure will reconcile the amounts during the settlement.

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction.

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL. type description here

Parameters:

body (PurchasesDecryptedFlowRequest1) —
Required parameter: TODO:

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1437

def purchases_decrypted_flow_1(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PurchaseSuccess4.method(:from_hash))
                .is_api_response(true))
    .execute
end

#purchases_encrypted_flow(body) ⇒ `ApiResponse`

To process a Google Pay transaction, a Purchase must first be created using the /purchases API. The Google Pay token must be included in the request under extraParam.googlepay_param. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Parameters in the request body:

Parameter	Notes
client.full_name	Conditional. But Recommended to pass the
complete name of the client. Atleast 2 words recommended.
client.email	Conditional. But Recommended to pass a correct email
id.
paymentMethod	Conditional. Mandatory if you are not using
Paysecure Cashier. Else Non Mandatory. Value: GOOGLEPAY
purchase.currency	Mandatory. ISO 4217 code for currency you want
to send the transaction in. This should be 'BRL' for PIX.
purchase.products.name	Mandatory.
purchase.products.price	Mandatory. Price in decimal format upto 2

decimals.
example 1:
EUR 5 , should be sent as 5.00
example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Mandatory.
Obtain from Dashboard section of your merchant account login. | | success_redirect | Mandatory.
URL to send the user if the transactions is successful. | | pending_redirect | Mandatory.
URL to send the user if the transactions is in progress state. | | failure_redirect | Mandatory
URL to send the user if the transactions has failed. |

Optional Parameters

expireInMin

This parameter, when passed in the PayIn request, sets the time window within which a customer should make the Interac payment through their bank's app. If a customer doesn't complete the payment within the configured time window, the status of the payment will be marked as 'EXPIRED' in Paysecure. However, in certain cases, a payment made outside of this window could still be successful i.e. customer's account may be debited which would result in inconsistencies among Paysecure's, merchant's and customer's status of the transaction. To avoid such cases it is advised to set the expiry time limit appropriately and advise the customers to make payment within this window. However, if there is an inconsistency between the status at Paysecure and at customer's Bank, the merchant and Paysecure will reconcile the amounts during the settlement.

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction.

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL.

Flow Diagram:

description here

Parameters:

body (PurchasesEncryptedFlowRequest) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1108

def purchases_encrypted_flow(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PurchaseSuccess4.method(:from_hash))
                .is_api_response(true))
    .execute
end

#purchases_encrypted_flow_1(body) ⇒ `ApiResponse`

To process an Apple Pay transaction, a Purchase must be created using the /purchases API. The Apple Pay token must be included under extraParam.applepay_param. To generate a Purchase, you are required to provide the Brand ID (in the request body) and API key (in the header) Both can be located in the Dashboard section of your merchant account login. The request body structure is shown on the request body of the example request shown here. The following (see table below) are the mandatory parameters that are required to create a purchase request.

Parameters in the request body:

Parameter	Notes
client.full_name	Conditional. But Recommended to pass the
complete name of the client. Atleast 2 words recommended.
client.email	Conditional. But Recommended to pass a correct email
id.
paymentMethod	Conditional. Mandatory if you are not using
Paysecure Cashier. Else Non Mandatory. Value: APPLEPAY
purchase.currency	Mandatory. ISO 4217 code for currency you want
to send the transaction in. This should be 'BRL' for PIX.
purchase.products.name	Mandatory.
purchase.products.price	Mandatory. Price in decimal format upto 2

decimals.
example 1:
EUR 5 , should be sent as 5.00
example 2:
USD 10 and 37 cents , should be sent as 10.37 | | brand_id | Mandatory.
Obtain from Dashboard section of your merchant account login. | | success_redirect | Mandatory.
URL to send the user if the transactions is successful. | | pending_redirect | Mandatory.
URL to send the user if the transactions is in progress state. | | failure_redirect | Mandatory
URL to send the user if the transactions has failed. |

Optional Parameters

expireInMin

This parameter, when passed in the PayIn request, sets the time window within which a customer should make the Interac payment through their bank's app. If a customer doesn't complete the payment within the configured time window, the status of the payment will be marked as 'EXPIRED' in Paysecure. However, in certain cases, a payment made outside of this window could still be successful i.e. customer's account may be debited which would result in inconsistencies among Paysecure's, merchant's and customer's status of the transaction. To avoid such cases it is advised to set the expiry time limit appropriately and advise the customers to make payment within this window. However, if there is an inconsistency between the status at Paysecure and at customer's Bank, the merchant and Paysecure will reconcile the amounts during the settlement.

merchantRef

The merchantRef parameter, although not mandatory, is strongly advised for merchants to specify. Its inclusion offers two significant advantages for the merchant:

Prevention of Duplicate Requests: When a merchantRef is utilized, it acts as a unique identifier. This means that if a second purchase request is made using the same merchantRef (reference number), the system will recognize it and prevent duplicate transactions from occurring. This prevents unintended or duplicate purchases.
Facilitation of Transaction Retrieval: In situations where the response from the initial purchase request times out or the 'purchaseId' isn't received, having the merchantRef allows the merchant to retrieve detailed transaction information. This ensures they can track and access the specific purchase details related to that reference, even if the immediate response was not received.

However, if the merchant does not specify the 'merchantRef' parameter, the platform will automatically assign and use an internal 'purchaseId' as a reference for that transaction.

paymentMethod

The paymentMethod parameter identifies which payment solution merchant wants to use to perform a transaction. If parameter is provided, than Paysecure will perform direct payment with the selected payment method instead of loading Paysecure URL. type description here

Parameters:

body (PurchasesEncryptedFlowRequest1) —
Required parameter: TODO:

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1344

def purchases_encrypted_flow_1(body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/purchases',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(PurchaseSuccess4.method(:from_hash))
                .is_api_response(true))
    .execute
end

#refund ⇒ `ApiResponse`

This API is used to initate refund (Full Refund) of the purchases that have status as PAID can be initiated for refund Once the refund has been initiated, the status of the purchase would become REFUND_IN_PROCESS and once the refund has been approved by the bank, the status woud become REFUNDED Purchase ID is mandatory for this API. Currently we don't support partial refunds.

Response Examples

In the response examples you can see instances of both successful and unsuccessful in refund of purchases.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 315

def refund
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/purchaseid/refund',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(RefundSuccess.method(:from_hash))
                .is_api_response(true)
                .local_error('400',
                             'Bad Request',
                             RefundErrorException))
    .execute
end

#refund1 ⇒ `ApiResponse`

This API is used to initate refund of the purchases that have status as PAID can be initiated for refund Once the refund has been initiated, the status of the purchase would become REFUND_IN_PROCESS and once the refund has been approved by the bank, the status woud become REFUNDED Purchase ID is mandatory for this API. Currently we don't support partial refunds.

Response Examples

In the response examples you can see instances of both successful and unsuccessful in refund of purchases.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 1675

def refund1
  @api_call
    .request(new_request_builder(HttpMethodEnum::GET,
                                 '/api/v1/purchases/657af976c3fceb7beb30eeb4/refund',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(RefundSuccess1.method(:from_hash))
                .is_api_response(true)
                .local_error('400',
                             'Bad Request',
                             RefundErrorException))
    .execute
end

#revoke_mandate(accept, brandid, body) ⇒ `ApiResponse`

Required for cases where the Paysecure is handling the scheduling of recurring payments. Use this API to revoke/cancel an ACTIVE mandate. Note: Revoking a mandate should be done at the same instance this API is called. The mandate status should be updated to “REVOKED” at the same instant. description here

Parameters:

accept (String) —
Required parameter: TODO: type description here
brandid (String) —
Required parameter: TODO: type description here
body (RevokeMandateRequest) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2209

def revoke_mandate(accept,
                   brandid,
                   body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/mandate',
                                 Server::SERVER_3)
               .header_param(new_parameter(accept, key: 'Accept')
                              .is_required(true))
               .header_param(new_parameter(brandid, key: 'Brandid')
                              .is_required(true))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json; charset=utf-8', key: 'content-type'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success39.method(:from_hash))
                .is_api_response(true))
    .execute
end

#s2_s(s2s, body) ⇒ `ApiResponse`

This API would be the 2nd in sequence to call if the call to /purchases/ was successful in step 1. and you want to do the transaction via Server-to-Server mode. The request body would contain the details of the card that's to be transacted upon.

Mandatory parameters in request body:

Parameter	Notes
remote_ip	IP address of the customer’s device used for transaction.
Helps in fraud checks and risk scoring. Ex- 157.38.242.7
remember_card	"on" or "off" if you want us to store the card details
on our end.
user_agent	Full browser and operating system details captured from
HTTP header. EX- Chrome/5.0 (X11; Linux x86_64)
accept_header	Browser’s accepted content types (from HTTP header).
Used for validating request origin and device info. EX- text/html

Note: If you want to use token_reference for doing a card transaction, please have a look at Network Tokenisation Section.

Essential parameters in request body:

Parameter	Notes
cardholder_name	Name of the cardholder
card_number	The card numbers Must be 10-20 characters.
expires	must be greater than the current month/year. MM/YY format.
cvc	3 or 4 digit

Other optional parameters in request body:

Parameter	Notes
language	Preferred language of the user’s browser . EX - en-US
java_enabled	Indicates if Java is enabled in the browser. Helps PSPs
in device profiling. Ex- true/false
javascript_enabled	Indicates if JavaScript is enabled in the client
browser. Used for 3DS or risk-based checks. Ex- true
color_depth	Bit depth of the display screen. Ex- 24
utc_offset	Difference in minutes between local time and UTC. Used for
location and timezone checks. Ex- 330
screen_width	Width of the device screen in pixels. Used in device
profiling. Ex- 1920
screen_height	Height of the device screen in pixels. Ex- 1080

Successful Response

If all the details are correct you'll get a 202 response with staus as Pending

{
    "status": "pending",
    "callback_url":
"https://paysecure.net/payment/63bd0bf80fb42a076e8a4dd1/",
    "method": "GET"
}

If the response code is 202, after receiving the response body, direct the customer to the callback_url provided in the response.

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details. | Error Messages | | --- | | Client Ip could not be matched with Merchant Ip | | Invalid Card Information | | Card is Blocked | | Different Type of key used to create purchase and payment | | You charges setting is incomplete .Plese Contact to adminstrartor. | | Allowed Attempt for this Transaction has been consumed | | Invalid Card Expiry(Valid Format:MM/YY) must be greator than current month/year | | Customer profile is Blocked | | Customer/Card not allowed for transaction | description here

Parameters:

s2s (TrueClass | FalseClass) —
Required parameter: TODO: type
body (S2Srequest) —
Required parameter: TODO: type description here

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 205

def s2_s(s2s,
         body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/p/purchaseid',
                                 Server::SERVER_3)
               .query_param(new_parameter(s2s, key: 's2s')
                             .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success1.method(:from_hash))
                .is_api_response(true)
                .local_error('401',
                             'Unauthorized',
                             FailureException))
    .execute
end

#s2_s1(s2s, body) ⇒ `ApiResponse`

This API would be the 2nd in sequence to call if the call to /purchases/ was successful in step 1. and you want to do the transaction via Server-to-Server mode. The request body would contain the details of the card that's to be transacted upon.

Mandatory parameters in request body:

Parameter	Notes
remote_ip	IP address of the customer’s device used for transaction.
Helps in fraud checks and risk scoring. Ex- 157.38.242.7
user_agent	Full browser and operating system details captured from
HTTP header. EX- Chrome/5.0 (X11; Linux x86_64)
accept_header	Browser’s accepted content types (from HTTP header).
Used for validating request origin and device info. EX- text/html

Note: If you want to use token_reference for doing a card transaction, please have a look at Network Tokenisation Section.

Essential parameters in request body:

Parameter	Notes
cardholder_name	Name of the cardholder
card_number	The card numbers Must be 10-20 characters.
expires	must be greater than the current month/year.
cvc	3 or 4 digit

** Other optional parameters in request body:**

Parameter	Notes
language	Preferred language of the user’s browser . EX - en-US
java_enabled	Indicates if Java is enabled in the browser. Helps PSPs
in device profiling. Ex- true/false
javascript_enabled	Indicates if JavaScript is enabled in the client
browser. Used for 3DS or risk-based checks. Ex- true
color_depth	Bit depth of the display screen. Ex- 24
utc_offset	Difference in minutes between local time and UTC. Used for
location and timezone checks. Ex- 330
screen_width	Width of the device screen in pixels. Used in device
profiling. Ex- 1920
screen_height	Height of the device screen in pixels. Ex- 1080

Successful Response

If all the details are correct you'll get a 202 response with staus as Pending

{
    "status": "pending",
    "callback_url":
"https://paysecure.net/payment/63bd0bf80fb42a076e8a4dd1/",
    "method": "GET"
}

If the response code is 202, after receiving the response body, direct the customer to the callback_url provided in the response.

Errors

If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details. | Error Messages | | --- | | Client Ip could not be matched with Merchant Ip | | Invalid Card Information | | Card is Blocked | | Different Type of key used to create purchase and payment | | You charges setting is incomplete .Plese Contact to adminstrartor. | | Allowed Attempt for this Transaction has been consumed | | Invalid Card Expiry(Valid Format:MM/YY) must be greator than current month/year | | Customer profile is Blocked | | Customer/Card not allowed for transaction | description here

Parameters:

s2s (TrueClass | FalseClass) —
Required parameter: TODO: type
body (S2Srequest) —
Required parameter: TODO: type description here

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2904

def s2_s1(s2s,
          body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/p/64bff4fff63e36669499e9c8',
                                 Server::SERVER_3)
               .query_param(new_parameter(s2s, key: 's2s')
                             .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success1.method(:from_hash))
                .is_api_response(true)
                .local_error('401',
                             'Unauthorized',
                             FailureException))
    .execute
end

#s2_s_api(s2s, body) ⇒ `ApiResponse`

This API would be the 2nd in sequence to call if the call to /purchases/ was successful in step 1. and you want to do the transaction via Server-to-Server mode. The request body would contain the details of the card that's to be transacted upon.

Mandatory parameters in request body:

Parameter	Notes
remote_ip	IP address of the customer’s device used for transaction.
Helps in fraud checks and risk scoring. Ex- 157.38.242.7
user_agent	Full browser and operating system details captured from
HTTP header. EX- Chrome/5.0 (X11; Linux x86_64)
accept_header	Browser’s accepted content types (from HTTP header).
Used for validating request origin and device info. EX- text/html

Essential parameters in request body:

Parameter	Notes
cardholder_name	Name of the cardholder
card_number	The card numbers Must be 10-20 characters.
expires	must be greater than the current month/year.
cvc	3 or 4 digit

** Other optional parameters in request body:**

Parameter	Notes
language	Preferred language of the user’s browser . EX - en-US
java_enabled	Indicates if Java is enabled in the browser. Helps PSPs
in device profiling. Ex- true/false
javascript_enabled	Indicates if JavaScript is enabled in the client
browser. Used for 3DS or risk-based checks. Ex- true
color_depth	Bit depth of the display screen. Ex- 24
utc_offset	Difference in minutes between local time and UTC. Used for
location and timezone checks. Ex- 330
screen_width	Width of the device screen in pixels. Used in device
profiling. Ex- 1920
screen_height	Height of the device screen in pixels. Ex- 1080

Successful Response If all the details are correct you'll get a 202 response with staus as Pending

{
    "status": "pending",
    "callback_url":
"https://paysecure.net/payment/63bd0bf80fb42a076e8a4dd1/",
    "method": "GET"
}

If the response code is 202, after receiving the response body, direct the customer to the callback_url provided in the response. Errors If there are any errors then it'll be in the format of :

{
    "message": "descriptive error message",
    "code": "error_code"
}

Please see the Status Code section for further details. | Error Messages | | --- | | Client Ip could not be matched with Merchant Ip | | Invalid Card Information | | Card is Blocked | | Different Type of key used to create purchase and payment | | You charges setting is incomplete .Plese Contact to adminstrartor. | | Allowed Attempt for this Transaction has been consumed | | Invalid Card Expiry(Valid Format:MM/YY) must be greator than current month/year | | Customer profile is Blocked | | Customer/Card not allowed for transaction | description here here

Parameters:

s2s (TrueClass | FalseClass) —
Required parameter: TODO: type
body (S2SApiRequest) —
Required parameter: TODO: type description

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2109

def s2_s_api(s2s,
             body)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/p/64bff4fff63e36669499e9c8',
                                 Server::SERVER_3)
               .query_param(new_parameter(s2s, key: 's2s')
                             .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success1.method(:from_hash))
                .is_api_response(true))
    .execute
end

#s2_s_payment(s2s, body, brand_id) ⇒ `ApiResponse`

S2S Payment

Process a payment using a saved card's token_reference. Paysecure resolves the token reference to the underlying network token and processes the payment securely. If the selected MID does not accept tokens, Paysecure automatically falls back to the card number.

S2S Input Scenarios

The S2S API accepts different input types depending on the scenario:

Scenario	What to Send	What Paysecure Does
New card (first-time customer)	Full card details	Paysecure

tokenises the card. If the MID supports tokens, the transaction uses the token; otherwise, the card number is used. | | Returning customer (tokenised with Paysecure) | token_reference from List Saved Cards | Paysecure uses the stored token and generates a new cryptogram. Falls back to card number if MID doesn't accept tokens. |

Request Body

Field	Type	Required	Description
`token_reference`	string	Conditional	Token reference from List
Saved Cards. Required when paying with a Paysecure-tokenised card.
`cvc`	string	Yes	Card CVC/CVV. Required even when
`token_reference` is provided, for 3DS authentication.
`remember_card`	string	No	`"on"` to save card, `"off"` to skip.
Use `"off"` with saved tokens.
`remote_ip`	string	Yes	Cardholder's IP address.
`user_agent`	string	Yes	Browser User-Agent string.
`accept_header`	string	Yes	Browser Accept header.
`language`	string	Yes	Browser language (e.g., `"en-US"`).
`java_enabled`	boolean	Yes	Java enabled in browser.
`javascript_enabled`	boolean	Yes	JavaScript enabled in browser.
`color_depth`	integer	Yes	Screen colour depth.
`utc_offset`	integer	Yes	UTC timezone offset (minutes).
`screen_width`	integer	Yes	Screen width (px).
`screen_height`	integer	Yes	Screen height (px).

Token Reference in Response

Scenario 1 (New card via S2S): token_reference returned in Check Status and Webhook.
Scenario 2 (Existing token_reference): token_reference returned in response and Webhook.

Important Notes

CVC is required even when using a token_reference.
All browser fields are required for 3D Secure authentication.
Response follows the standard Paysecure payment response format. server-to-server requests. here

Parameters:

s2s (TrueClass | FalseClass) —
Required parameter: Must be "true" for
body (S2SPaymentRequest) —
Required parameter: TODO: type description
brand_id (String) —
Required parameter: TODO: type description here

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 2533

def s2_s_payment(s2s,
                 body,
                 brand_id)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/api/v1/p/{brandId}',
                                 Server::SERVER_3)
               .query_param(new_parameter(s2s, key: 's2s')
                             .is_required(true))
               .header_param(new_parameter('application/json', key: 'Content-Type'))
               .body_param(new_parameter(body)
                            .is_required(true))
               .template_param(new_parameter(brand_id, key: 'brandId')
                                .is_required(true)
                                .should_encode(true))
               .header_param(new_parameter('application/json', key: 'accept'))
               .body_serializer(proc do |param| param.to_json unless param.nil? end))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success1.method(:from_hash))
                .is_api_response(true))
    .execute
end

#session ⇒ `ApiResponse`

OVERVIEW The createSession API is designed to initiate a payment session for a customer after their profile has been created via the createCustomer API. The session is automatically generated at the backend on the merchant’s checkout URL. This session allows the customer to continue with their transaction without having to manually interact with the session URL, and ensures the session remains active until the payment is completed or the session expires. This API improves the user experience by reducing transaction failures and enhancing the overall payment process, thus reducing transaction churn rates.

Mandatory Parameters

Parameter	Type	Description	Example
customerId	String	The unique ID of the customer (generated from
createCustomer).	6731a609b6bb5a43ad66c4a6

Usage Flow

Customer completes the createCustomer API: Once the customer is created via the createCustomer API, the merchant proceeds to call the createSession API to generate a session.
Merchant sends createSession request: The merchant sends a POST request to the createSession API with the customer’s customerId and the merchant’s brandId.
Session created automatically on the checkout URL: PaySecure creates the session and associates it with the merchant’s checkout page. This session remains active on the backend, allowing the customer to continue the payment process without interruption.
Customer proceeds to checkout: The customer is redirected to the checkout page as part of the merchant's payment flow, where the session is automatically validated. The session remains active for a set period, allowing the customer to complete the payment without needing to manually interact with the session URL.
Session Expiry: The session expires after the set expiration time (expiryOn), ensuring the payment process is completed within the defined window. Default is 15 mins from the creation time.

Benefits

Seamless Checkout: The session URL is automatically generated and active at the backend, ensuring a smoother and uninterrupted customer experience.
Reduced Transaction Failures: By ensuring the session remains active during the payment process, the chances of transaction failures due to session timeouts are minimized.
Improved User Experience: The customer does not need to click on a session URL or navigate away from the page, leading to faster and more secure payment processing.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 758

def session
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/createSession',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success14.method(:from_hash))
                .is_api_response(true)
                .local_error('400',
                             'Bad Request',
                             InvalidSessionException))
    .execute
end

#session1 ⇒ `ApiResponse`

OVERVIEW The createSession API is designed to initiate a payment session for a customer after their profile has been created via the createCustomer API. The session is automatically generated at the backend on the merchant’s checkout URL. This session allows the customer to continue with their transaction without having to manually interact with the session URL, and ensures the session remains active until the payment is completed or the session expires. This API improves the user experience by reducing transaction failures and enhancing the overall payment process, thus reducing transaction churn rates.

Mandatory Parameters

Parameter	Type	Description	Example
customerId	String	The unique ID of the customer (generated from
createCustomer).	6731a609b6bb5a43ad66c4a6

Usage Flow

Customer completes the createCustomer API: Once the customer is created via the createCustomer API, the merchant proceeds to call the createSession API to generate a session.
Merchant sends createSession request: The merchant sends a POST request to the createSession API with the customer’s customerId and the merchant’s brandId.
Session created automatically on the checkout URL: PaySecure creates the session and associates it with the merchant’s checkout page. This session remains active on the backend, allowing the customer to continue the payment process without interruption.
Customer proceeds to checkout: The customer is redirected to the checkout page as part of the merchant's payment flow, where the session is automatically validated. The session remains active for a set period, allowing the customer to complete the payment without needing to manually interact with the session URL.
Session Expiry: The session expires after the set expiration time (expiryOn), ensuring the payment process is completed within the defined window. Default is 15 mins from the creation time.

Benefits

Seamless Checkout: The session URL is automatically generated and active at the backend, ensuring a smoother and uninterrupted customer experience.
Reduced Transaction Failures: By ensuring the session remains active during the payment process, the chances of transaction failures due to session timeouts are minimized.
Improved User Experience: The customer does not need to click on a session URL or navigate away from the page, leading to faster and more secure payment processing.

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 966

def session1
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/createSession',
                                 Server::SERVER_3)
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(Success14.method(:from_hash))
                .is_api_response(true)
                .local_error('400',
                             'Bad Request',
                             InvalidSessionException))
    .execute
end

#whitelist_upload(csv_file) ⇒ `ApiResponse`

Overview

The merchant can upload a list of whitelist cards and email ids through this API. All cards successfully uploaded will be considered whitelisted and allowed for that merchant.

Mandatory parameters in the request body:

Parameter	Notes
csvFile	Upload a CSV file

Please note:

CSV file should contain the following headers (both mandatory)
1. card_number
2. email_id
CSV file should not be empty

public class FileUploader {
    public static void uploadFile(String apiUrl, String filePath, String
authorizationHeader) {
        try {
            File file = new File(filePath);
            OkHttpClient client = new OkHttpClient();
            RequestBody requestBody = new
MultipartBody.Builder().setType(MultipartBody.FORM)
                    .addFormDataPart("csvFile", file.getName(),
RequestBody.create(MediaType.parse("text/csv"), file))
                    .build();
            Request request = new
Request.Builder().url(apiUrl).post(requestBody)
                    .addHeader("Authorization",
authorizationHeader).build();
            Response response = client.newCall(request).execute();
            if (response.code() == 202) {
                System.out.println("File uploaded successfully!");
                System.out.println("Response: " +
response.body().string());
            } else {
                System.out.println("File upload failed.");
                System.out.println("Status: " + response.code());
                System.out.println("Error: " + response.body().string());
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    public static void main(String[] args) {
        String apiUrl = "https://{{base_url}}/api/v1/whitelist/upload";
        String filePath = "whitelist.csv.file.path";
        String authorizationHeader = "Bearer YOUR API KEY";
        uploadFile(apiUrl, filePath, authorizationHeader);
    }
}

description here

Parameters:

csv_file (File | UploadIO) —
Required parameter: TODO: type

Returns:

(ApiResponse) —
Complete http response with raw body and status code.

# File 'lib/paysecure_api_documentation_live/apis/ap_is_api.rb', line 490

def whitelist_upload(csv_file)
  @api_call
    .request(new_request_builder(HttpMethodEnum::POST,
                                 '/api/v1/whitelist/upload',
                                 Server::SERVER_3)
               .multipart_param(new_parameter(csv_file, key: 'csvFile')
                                 .is_required(true)
                                 .default_content_type('application/octet-stream'))
               .header_param(new_parameter('application/json', key: 'accept')))
    .response(new_response_handler
                .deserializer(APIHelper.method(:custom_type_deserializer))
                .deserialize_into(WhitelistUploadSuccess.method(:from_hash))
                .is_api_response(true)
                .local_error('401',
                             'Unauthorized',
                             WhitelistUploadFailureException))
    .execute
end

Overview

Constant Summary

Constants inherited from BaseApi

Instance Attribute Summary

Attributes inherited from BaseApi

Instance Method Summary collapse

Overview Paysecure supports the concept of whitelisted cards.

Delete Token Permanently delete a saved card and deactivate the associated network token.

List Saved Cards Retrieve all saved card tokens for a given customer.

Overview The Original Credit Transaction (OCT), commonly referred to as Push to Card, enables merchants to facilitate near-instantaneous fund transfers directly to a customer’s eligible Visa or Mastercard debit or credit card.

Overview The Original Credit Transaction (OCT), commonly referred to as Push to Card, enables merchants to facilitate near-instantaneous fund transfers directly to a customer’s eligible Visa or Mastercard debit or credit card.

Purchase Initiate a payment transaction.

S2S Payment Process a payment using a saved card's token_reference.

Overview The merchant can upload a list of whitelist cards and email ids through this API.

Methods inherited from BaseApi

Constructor Details

Instance Method Details

#cancel ⇒ ApiResponse

#cancel1 ⇒ ApiResponse

#capture(body) ⇒ ApiResponse

#check_white_list(accept, body) ⇒ ApiResponse

Overview

Mandatory Parameters (in body)

Other parameters:

Response Examples

#create_customer(brand_id, body) ⇒ ApiResponse

User Flow

Benefits

Implementing createCustomer on merchant site:

#create_purchase_cit(body) ⇒ ApiResponse

Additional parameters for this usecase:

#create_purchase_mit(accept, body) ⇒ ApiResponse

#create_session_cit(brand_id, body) ⇒ ApiResponse

Mandatory Parameters

Additional parameters for this usecase:

Usage Flow

Benefits

#delete_token(token_reference) ⇒ ApiResponse

Delete Token

Path Parameters

Important Notes

When to Delete

#get_customer(brand_id, accept) ⇒ ApiResponse

Request

Response

#get_mandate(accept, brand_id) ⇒ ApiResponse

Response parameters:

#get_status ⇒ ApiResponse

Mandatory

Possible Value of Status

Response Examples

Error Details

Errors

#get_status1(purchase_id) ⇒ ApiResponse

Mandatory

Possible Value of Status

Response Examples

Error Details

Errors

#get_status11 ⇒ ApiResponse

Mandatory

Possible Value of Status

Response Examples

Error Details

Errors

#get_status2(purchase_id) ⇒ ApiResponse

Mandatory

Possible Value of Status

Response Examples

Error Details

Errors

#get_status3(purchase_id) ⇒ ApiResponse

Mandatory

Possible Value of Status

Response Examples

Error Details

Errors

#get_status4(purchase_id) ⇒ ApiResponse

Mandatory

S2S Payment Process a payment using a saved card's `token_reference`.

#cancel ⇒ `ApiResponse`

#cancel1 ⇒ `ApiResponse`

#capture(body) ⇒ `ApiResponse`

#check_white_list(accept, body) ⇒ `ApiResponse`

#create_customer(brand_id, body) ⇒ `ApiResponse`

#create_purchase_cit(body) ⇒ `ApiResponse`

#create_purchase_mit(accept, body) ⇒ `ApiResponse`

#create_session_cit(brand_id, body) ⇒ `ApiResponse`

#delete_token(token_reference) ⇒ `ApiResponse`

#get_customer(brand_id, accept) ⇒ `ApiResponse`

#get_mandate(accept, brand_id) ⇒ `ApiResponse`

#get_status ⇒ `ApiResponse`

#get_status1(purchase_id) ⇒ `ApiResponse`

#get_status11 ⇒ `ApiResponse`

#get_status2(purchase_id) ⇒ `ApiResponse`

#get_status3(purchase_id) ⇒ `ApiResponse`

#get_status4(purchase_id) ⇒ `ApiResponse`

#get_status5(purchase_id) ⇒ `ApiResponse`

#list_mandates(customer_id, email, accept, brand_id) ⇒ `ApiResponse`

#list_saved_cards ⇒ `ApiResponse`

#pause_mandate(accept, brand_id, body) ⇒ `ApiResponse`

#pay_out(accept, body) ⇒ `ApiResponse`

#pay_out1(accept, body) ⇒ `ApiResponse`

#payment_methods(brand_id) ⇒ `ApiResponse`

#payment_to_be_initiated_from_client_browser(accept) ⇒ `ApiResponse`

#purchase(body) ⇒ `ApiResponse`

#purchase1(body) ⇒ `ApiResponse`

#purchase2(body) ⇒ `ApiResponse`

#purchase3(body) ⇒ `ApiResponse`

#purchases(body) ⇒ `ApiResponse`

#purchases1(body) ⇒ `ApiResponse`