com.onlinepayments.domain

Class SubsequentCardPaymentMethodSpecificInput

java.lang.Object

com.onlinepayments.domain.SubsequentCardPaymentMethodSpecificInput

public class SubsequentCardPaymentMethodSpecificInput
extends Object

Object containing the specific input details for subsequent card payments

Constructor Summary

Constructors

Constructor and Description
SubsequentCardPaymentMethodSpecificInput()

Method Summary

Modifier and Type	Method and Description
String	getAuthorizationMode() Determines the type of the authorization that will be used.
String	getSchemeReferenceData() This is the unique Scheme Reference Data from the initial transaction that was performed with a Strong Customer Authentication.
String	getSubsequentType() Determines the type of the subsequent that will be used.
String	getToken() ID of the token to use to create the payment.
String	getTransactionChannel() Indicates the channel via which the payment is created.
void	setAuthorizationMode(String value) Determines the type of the authorization that will be used.
void	setSchemeReferenceData(String value) This is the unique Scheme Reference Data from the initial transaction that was performed with a Strong Customer Authentication.
void	setSubsequentType(String value) Determines the type of the subsequent that will be used.
void	setToken(String value) ID of the token to use to create the payment.
void	setTransactionChannel(String value) Indicates the channel via which the payment is created.
SubsequentCardPaymentMethodSpecificInput	withAuthorizationMode(String value) Determines the type of the authorization that will be used.
SubsequentCardPaymentMethodSpecificInput	withSchemeReferenceData(String value) This is the unique Scheme Reference Data from the initial transaction that was performed with a Strong Customer Authentication.
SubsequentCardPaymentMethodSpecificInput	withSubsequentType(String value) Determines the type of the subsequent that will be used.
SubsequentCardPaymentMethodSpecificInput	withToken(String value) ID of the token to use to create the payment.
SubsequentCardPaymentMethodSpecificInput	withTransactionChannel(String value) Indicates the channel via which the payment is created.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

SubsequentCardPaymentMethodSpecificInput

public SubsequentCardPaymentMethodSpecificInput()

Method Detail

getAuthorizationMode

public String getAuthorizationMode()

Determines the type of the authorization that will be used. Allowed values: * FINAL_AUTHORIZATION - The payment creation results in an authorization that is ready for capture. Final authorizations can't be reversed and need to be captured for the full amount within 7 days. * PRE_AUTHORIZATION - The payment creation results in a pre-authorization that is ready for capture. Pre-authortizations can be reversed and can be captured within 30 days. The capture amount can be lower than the authorized amount. * SALE - The payment creation results in an authorization that is already captured at the moment of approval. Only used with some acquirers, ignored for acquirers that don't support this. In case the acquirer doesn't allow this to be specified the authorizationMode is 'unspecified', which behaves similar to a final authorization.

setAuthorizationMode

public void setAuthorizationMode(String value)

Determines the type of the authorization that will be used. Allowed values: * FINAL_AUTHORIZATION - The payment creation results in an authorization that is ready for capture. Final authorizations can't be reversed and need to be captured for the full amount within 7 days. * PRE_AUTHORIZATION - The payment creation results in a pre-authorization that is ready for capture. Pre-authortizations can be reversed and can be captured within 30 days. The capture amount can be lower than the authorized amount. * SALE - The payment creation results in an authorization that is already captured at the moment of approval. Only used with some acquirers, ignored for acquirers that don't support this. In case the acquirer doesn't allow this to be specified the authorizationMode is 'unspecified', which behaves similar to a final authorization.

withAuthorizationMode

public SubsequentCardPaymentMethodSpecificInput withAuthorizationMode(String value)

Determines the type of the authorization that will be used. Allowed values: * FINAL_AUTHORIZATION - The payment creation results in an authorization that is ready for capture. Final authorizations can't be reversed and need to be captured for the full amount within 7 days. * PRE_AUTHORIZATION - The payment creation results in a pre-authorization that is ready for capture. Pre-authortizations can be reversed and can be captured within 30 days. The capture amount can be lower than the authorized amount. * SALE - The payment creation results in an authorization that is already captured at the moment of approval. Only used with some acquirers, ignored for acquirers that don't support this. In case the acquirer doesn't allow this to be specified the authorizationMode is 'unspecified', which behaves similar to a final authorization.

getSchemeReferenceData

public String getSchemeReferenceData()

This is the unique Scheme Reference Data from the initial transaction that was performed with a Strong Customer Authentication. In case this value is unknown, a Scheme Reference of an earlier transaction that was part of the same sequence can be used as a fall-back. Still, it is strongly advised to submit this value for any Merchant Initiated Transaction or any recurring transaction (hereby defined as "Subsequent").

setSchemeReferenceData

public void setSchemeReferenceData(String value)

This is the unique Scheme Reference Data from the initial transaction that was performed with a Strong Customer Authentication. In case this value is unknown, a Scheme Reference of an earlier transaction that was part of the same sequence can be used as a fall-back. Still, it is strongly advised to submit this value for any Merchant Initiated Transaction or any recurring transaction (hereby defined as "Subsequent").

withSchemeReferenceData

public SubsequentCardPaymentMethodSpecificInput withSchemeReferenceData(String value)

This is the unique Scheme Reference Data from the initial transaction that was performed with a Strong Customer Authentication. In case this value is unknown, a Scheme Reference of an earlier transaction that was part of the same sequence can be used as a fall-back. Still, it is strongly advised to submit this value for any Merchant Initiated Transaction or any recurring transaction (hereby defined as "Subsequent").

getSubsequentType

public String getSubsequentType()

Determines the type of the subsequent that will be used. Allowed values: * Recurring - Transactions processed at fixed, regular intervals not to exceed one year between Transactions, representing an agreement between a cardholder and a merchant to purchase goods or services provided over a period of time. Note that a recurring MIT transaction is initiated by the merchant (payee) not the customer (payer) and so is out of scope of PSD2. Recurring transactions that are in scope of PSD2 (and therefore may benefit from the recurring transaction exemption) are those that are customer (payer) initiates, e.g. standing orders set up from a bank account. * Unscheduled - A transaction using a stored credential for a fixed or variable amount that does not occur on a scheduled or regularly occurring transaction date, where the cardholder has provided consent for the merchant to initiate one or more future transactions which are not initiated by the cardholder. This transaction type is based on an agreement with the cardholder and is not to be confused with cardholder initiated transactions performed with stored credentials (CITs are in scope of PSD2 whereas UCOF transactions are MITs and thus out of scope). * Installment - Installment payments describe a single purchase of goods or services billed to a cardholder in multiple transactions over a period of time agreed by the cardholder and merchant. * NoShow - A No-show is a transaction where the merchant is enabled to charge for services which the cardholder entered into an agreement to purchase but did not meet the terms of the agreement. * DelayedCharge - A delayed charge is typically used in hotel, cruise lines and vehicle rental payment scenarios to perform a supplemental account charge after original services are rendered. * Reauthorisation - A Reauthorization is a purchase made after the original purchase and can reflect a number of specific conditions. Common scenarios include delayed/split shipments and extended stays/rentals. * Resubmission - This is an event that occurs when the original purchase occurred, but the merchant was not able to get authorization at the time the goods or services were provided. This is only applicable to contactless transit transactions.

setSubsequentType

public void setSubsequentType(String value)

Determines the type of the subsequent that will be used. Allowed values: * Recurring - Transactions processed at fixed, regular intervals not to exceed one year between Transactions, representing an agreement between a cardholder and a merchant to purchase goods or services provided over a period of time. Note that a recurring MIT transaction is initiated by the merchant (payee) not the customer (payer) and so is out of scope of PSD2. Recurring transactions that are in scope of PSD2 (and therefore may benefit from the recurring transaction exemption) are those that are customer (payer) initiates, e.g. standing orders set up from a bank account. * Unscheduled - A transaction using a stored credential for a fixed or variable amount that does not occur on a scheduled or regularly occurring transaction date, where the cardholder has provided consent for the merchant to initiate one or more future transactions which are not initiated by the cardholder. This transaction type is based on an agreement with the cardholder and is not to be confused with cardholder initiated transactions performed with stored credentials (CITs are in scope of PSD2 whereas UCOF transactions are MITs and thus out of scope). * Installment - Installment payments describe a single purchase of goods or services billed to a cardholder in multiple transactions over a period of time agreed by the cardholder and merchant. * NoShow - A No-show is a transaction where the merchant is enabled to charge for services which the cardholder entered into an agreement to purchase but did not meet the terms of the agreement. * DelayedCharge - A delayed charge is typically used in hotel, cruise lines and vehicle rental payment scenarios to perform a supplemental account charge after original services are rendered. * Reauthorisation - A Reauthorization is a purchase made after the original purchase and can reflect a number of specific conditions. Common scenarios include delayed/split shipments and extended stays/rentals. * Resubmission - This is an event that occurs when the original purchase occurred, but the merchant was not able to get authorization at the time the goods or services were provided. This is only applicable to contactless transit transactions.

withSubsequentType

public SubsequentCardPaymentMethodSpecificInput withSubsequentType(String value)

Determines the type of the subsequent that will be used. Allowed values: * Recurring - Transactions processed at fixed, regular intervals not to exceed one year between Transactions, representing an agreement between a cardholder and a merchant to purchase goods or services provided over a period of time. Note that a recurring MIT transaction is initiated by the merchant (payee) not the customer (payer) and so is out of scope of PSD2. Recurring transactions that are in scope of PSD2 (and therefore may benefit from the recurring transaction exemption) are those that are customer (payer) initiates, e.g. standing orders set up from a bank account. * Unscheduled - A transaction using a stored credential for a fixed or variable amount that does not occur on a scheduled or regularly occurring transaction date, where the cardholder has provided consent for the merchant to initiate one or more future transactions which are not initiated by the cardholder. This transaction type is based on an agreement with the cardholder and is not to be confused with cardholder initiated transactions performed with stored credentials (CITs are in scope of PSD2 whereas UCOF transactions are MITs and thus out of scope). * Installment - Installment payments describe a single purchase of goods or services billed to a cardholder in multiple transactions over a period of time agreed by the cardholder and merchant. * NoShow - A No-show is a transaction where the merchant is enabled to charge for services which the cardholder entered into an agreement to purchase but did not meet the terms of the agreement. * DelayedCharge - A delayed charge is typically used in hotel, cruise lines and vehicle rental payment scenarios to perform a supplemental account charge after original services are rendered. * Reauthorisation - A Reauthorization is a purchase made after the original purchase and can reflect a number of specific conditions. Common scenarios include delayed/split shipments and extended stays/rentals. * Resubmission - This is an event that occurs when the original purchase occurred, but the merchant was not able to get authorization at the time the goods or services were provided. This is only applicable to contactless transit transactions.

getToken

public String getToken()

ID of the token to use to create the payment.

setToken

public void setToken(String value)

ID of the token to use to create the payment.

withToken

public SubsequentCardPaymentMethodSpecificInput withToken(String value)

ID of the token to use to create the payment.

getTransactionChannel

public String getTransactionChannel()

Indicates the channel via which the payment is created. Allowed values: * ECOMMERCE - The transaction is a regular E-Commerce transaction. * MOTO - The transaction is a Mail Order/Telephone Order. Defaults to ECOMMERCE.

setTransactionChannel

public void setTransactionChannel(String value)

Indicates the channel via which the payment is created. Allowed values: * ECOMMERCE - The transaction is a regular E-Commerce transaction. * MOTO - The transaction is a Mail Order/Telephone Order. Defaults to ECOMMERCE.

withTransactionChannel

public SubsequentCardPaymentMethodSpecificInput withTransactionChannel(String value)

Indicates the channel via which the payment is created. Allowed values: * ECOMMERCE - The transaction is a regular E-Commerce transaction. * MOTO - The transaction is a Mail Order/Telephone Order. Defaults to ECOMMERCE.