Visa

Visa cards (debit, credit, prepaid, etc.) are widely accepted in e-commerce and physical environments. Card tokenization and consumer authentication (via the 3-D Secure protocol) improve the consumer experience and security of payments.

Features	Details
Method	Credit/Debit Card, Sync
Merchant countries	Asia-Pacific/Europe
Consumer countries	Global
Processing currencies	All *
Increments	✅
Captures	✅
Partial/Multiple partial captures	✅️
Cancels	✅
Partial/Multiple partial cancels	⚠️ (Only one partial cancel is supported)
Refunds	✅
Partial/Multiple partial refunds	✅
Recurring	✅
Installments	-
Credits	✅
Disputes	✅
Min Amount	N/A
Account verification	✅

note

* Currencies with 0, 2, and 3 decimal places are supported. For currencies with 3 decimal places, the last digit of the amount must be zero; that is, the amount must be rounded to two decimal places.

3-D Secure

The 3-D Secure pass-through authorization model is the one supported in this region. This means the customer is authenticated using an external 3-D Secure MPI before the payment request is made. Authentication information is then included in the threedsPassThrough block of the payment request.

The following ecommerce indicator (ECI) values are supported:

• 05
• 06
• 07

Strong customer authentication (SCA) exemptions

• delegated_authentication
• low_value
• secure_corporate
• transaction_risk_analysis

Secure remote payments

Secure remote payments are supported. Cryptogram and other relevant information for the secure remote payment must be included in the secureRemotePayment block of the payment request.

Mail order/Telephone order (MOTO)

Mail and telephone orders are supported.

Account verification (Zero auth)

An account verification is an authorization request with an amount of 0.

Address verification service (AVS)

The address verification service is not supported.

Scheme transaction ID

The scheme transaction id (Visa Transaction ID) of an initial transaction is required for all merchant initiated transactions (MIT) in this region, either standing instruction MITs (e.g., subsequent payments in a recurring series) or industry practice MITs (e.g., no show). The scheme transaction id of an initial transaction is returned in the payment response of it.

Industry practices

The following industry practice types are supported:

• delayed_charges
• no_show
• reauthorization *
• resubmission *

Any customer initiated transaction (CIT) that includes an agreement between the cardholder and the merchant for a potential subsequent industry practice MIT, should be flagged with the industry practice type.

For example, when a customer is booking a hotel room in a hotel that charges a no-show fee if the customer doesn't show up, the transaction to book the hotel room should be flagged with industry practice set to no_show and no scheme transaction id as this is the CIT. If the customer doesn't show up, the transaction to charge the no-show fee will be a MIT transaction with industry practice set to no_show and the scheme transaction id returned in the previous CIT transaction.

Sample request for a customer initiated transaction that includes an agreement for a potential subsequent industry practice MIT:

{
  "processingAccountId": "2HdN2jq6XWmlkhqRC2gDTNYCvNH",
  "merchantReference": "B2A8734D-9450-4915-A63D-FE5C21F09550",
  "amount": {
    "value": 200,
    "currency": "hkd"
  },
  "paymentMethod": {
    "type": "visa",
    "visa": {
      "account": {
        "number": "4000000000000002",
        "expiryMonth": "1",
        "expiryYear": "2030",
        "cvv": "333"
      },
      "capture": "manual",
      "industryPractice": {
        "type": "no_show"
      }
    }
  }
}

If the agreement between the cardholder and the merchant for a potential subsequent industry practice MIT includes more than one type of industry practice, like no-show fee if the customer doesn't show up and delayed charges for mini bar expenses, choose one of them for the customer initiated transaction that sets the agreement up.

Issuer/scheme responses

When a transaction is processed, issuers and card schemes may include relevant information in their response. The following response fields for paymentMethod.type visa are supported in this region, and will contain the information provided by the issuer or card scheme if available:

• scheme:
  • approvalCode
  • avsResult
  • cvvResult
  • eci
  • transactionId
  • responseCode
  • responseCodeCategory

Auto-cancellation

Card schemes require a period of time within which the authorized amount must be captured. This period can vary depending on the Merchant Category Code (MCC), but is typically 7 days for Visa. Automatic cancellation is not currently being performed for Visa authorizations. Merchants are responsible for cancelling authorizations that remain uncaptured within the applicable period.

Payment flow

Payment

Request

{
  "processingAccountId": "2HdN2jq6XWmlkhqRC2gDTNYCvNH",
  "merchantReference": "B2A8734D-9450-4915-A63D-FE5C21F09550",
  "amount": {
    "value": 200,
    "currency": "hkd"
  },
  "paymentMethod": {
    "type": "visa",
    "visa": {
      "account": {
        "number": "4000000000000002",
        "expiryMonth": "1",
        "expiryYear": "2030",
        "cvv": "333"
      },
      "capture": "manual"
    }
  }
}

Response

{
  "id": "2DCszjHIf3Uy2ZQMrUrkB9R1ZqG",
  "merchantReference": "B2A8734D-9450-4915-A63D-FE5C21F09550",
  "status": "succeeded",
  "paymentMethod": {
    "type": "visa",
    "scheme": {
      "approvalCode": "565848",
      "cvvResult": "M"
    }
  }
}