INTEGRATION
ACCOUNTS
TRANSACTION ASSURANCE
CHARGES
REPORTS
DISPUTES & FRAUD
Authorization
The type.intent on the charge determines how an authorization is processed and how long it remains valid.
A Final Authorization is used when the transaction amount is known and will not change. This is the most common type of authorization for standard e-commerce purchases. The type.intent should be purchase.
A Pre-Authorization is used to reserve an estimated amount on a cardholder's account. It is ideal for scenarios where the final amount may change or when there is a delay between authorization and clearing. The type.intent should be reservation. The authorized amount can be adjusted using increment or reversal actions. These are explained in the Charge Actions section.
The length of time an authorization is valid varies by network and authorization type.
Type | Mastercard | Visa |
Final Authorization | 7 days | 7 days (Card Not Present) 1 day (Card Present) |
Pre-Authorization | 30 days | 31 days - Lodging, Vehicle Rental, Cruise Lines 7 days - CNP, Transportation & Rental merchants (in the U.S. 3 days) 1 day (Card Present) |
The Address Verification Service (AVS) is a functionality provided by card networks and issuers to merchants to detect suspicious credit card transactions and prevent credit card fraud. It allows merchants and acquirers, especially those operating in an e-commerce environment, to compare various subfields such as postal code, name, address, email, and phone number provided by the customer at the point of sale with cardholder information on file with the issuer. Using AVS can significantly improve authorization approval rates, especially in the US, UK, and Canada.
Card issuers in the United States, Canada, and the United Kingdom must support AVS verification requests when submitted; however, using AVS is not mandatory for acquirers.
How to use AVS
Collect the cardholder's billing address during the checkout process.
In the
POST /chargesrequest, set the optional boolean fieldavs: true.When
avsistrue, thebillingAddressobject becomes a required field.The avs result is returned in the charge response in
authentication.avs
AVS Request
AVS Response
Silverflow returns a generic AVS result in authentication.avs field and the raw AVS result code from the card network under authorizationIsoFields.networkSpecificFields
Partial approval is a feature that allows a transaction to be partially approved if the cardholder's account has insufficient funds to cover the full purchase amount. Instead of a full decline, the issuer can approve a smaller amount up to the available balance. There is no guarantee that the issuer will partially approve transactions if it’s requested by the acquirer. When using partial approval, card networks advise using an alternate payment method to authorize the remaining amount.
How to use Partial Approval
In the
POST /chargesrequest, set the optional boolean fieldallowPartialApprovalastrueIf the issuer partially approves, the
status.authorizationwill be"approved-partial"and the approved amount will be reflected inamount.valueThe charge can then either be cleared or reversed based on if the merchant wants to proceed with the approved amount.
Partial approval is only supported for Visa & Mastercard
Dynamic descriptor is a feature that allows clients to customize the merchant name and city that appear on a cardholder's bank statement on a per-transaction basis. Using a clear and recognizable descriptor helps prevent customer confusion, which in turn reduces chargebacks and support inquiries. The optional dynamicDescriptor field can be used to provide the dynamic merchantName and merchantCity in authentication or authorization requests.
While the Silverflow platform can handle a wide array of character sets, downstream systems at the card networks and issuers often have stricter limitations, typically adhering to the ISO/IEC 8859 character set.
The card.holderName field is validated against a regular expression defined in the API reference. Any characters outside this definition, such as some special characters or symbols, will cause an API input validation error.This, for example, does include Latin-1 Supplement characters (from À to Ö, Ø to ö, and ø to ÿ) as allowable characters.
Please note that the exact definition of what is allowed on the downstream card network systems is very diverse. If a character is technically valid but not accepted by a downstream network system, the platform will automatically replace it with a Unicode substitution character to ensure the transaction can proceed.