Processing card payments

When a payment is attempted with an Adyen-issued card, you can control the approval through:

• Relayed authorization: Our platform sends you a webhook for each payment attempt. You have to approve or deny each payment attempt.
• Transaction rules: Create limitations based on conditions such as maximum amount, maximum number of transaction, or the types of payments allowed for a payment instrument. The rules are automatically applied to each payment attempt. Rules can be combined to facilitate different use cases.

You can choose to use both options. Transaction rules are applied first, serving as a filtering mechanism for payment attempts before sending you the relayed authorization. A payment that is rejected by transaction rules will not be sent to your system.

Once a payment has been approved or rejected, it creates a balance platform payment. After the inital payment, you will need to manage the payment lifecycle.

Relayed authorization

Relayed authorization gives you full control over payment processing.

With each relayed authorization webhook we send you, you have up to 1500 milliseconds to reply with an approval or a refusal. For the best customer experience, you should respond as quickly as possible and aim for a low average response time.

To start receiving webhooks, expose an endpoint. When a payment attempt comes in, we will send an HTTP POST with a relayed authorization message to the endpoint you specified.

Here is an example incoming request:

{
   "accountHolder" : {
      "description" : "Account holder 12345",
      "id" : "AH12345678900ABCDEF000GHF"
   },
   "amount" : {
      "currency" : "EUR",
      "value" : -1000
   },
   "authCode" : "000764",
   "authorisationDecision" : {
      "reasonCode" : "APPROVED",
      "status" : "Authorised",
      "statusCode" : "APPROVED"
   },
   "balanceAccount" : {
      "description" : "Account holder 12345 balance account",
      "id" : "AH12345678900ABCDEF000GHF"
   },
   "balanceMutations" : [
      {
         "balanceAfter" : {
            "currency" : "EUR",
            "value" : 800
         },
         "balanceBefore" : {
            "currency" : "EUR",
            "value" : 1800
         },
         "currency" : "EUR",
         "mutationAmount" : {
            "currency" : "EUR",
            "value" : -1000
         },
         "type" : "AuthorisedOutgoing"
      }
   ],
   "balancePlatform" : "BalancePlatformName",
   "id" : "TX12345678900000000000ABC",
   "merchantData" : {
      "mcc" : "7999",
      "merchantId" : "123456789012345",
      "nameLocation" : {
         "city" : "Amsterdam",
         "country" : "NLD",
         "name" : "MerchantName",
         "rawData" : "MerchantName        raw data     NLD"
      }
   },
   "paymentInstrument" : {
      "balanceAccountId" : "AH12345678900ABCDEF000GHF",
      "issuingCountryCode" : "GB",
      "product" : "mc",
      "type" : "card",
      "card" : {
         "cardholderName" : "Joe",
         "formFactor" : "virtual",
         "bin" : "555544",
         "expiration" : {
            "month" : "02",
            "year" : "2023"
         },
         "lastFour" : "6464"
      },
      "id" : "PI1234567890000ABCDE0000F",
      "status" : "Active"
   },
   "reference" : "MCS123456789",
   "validationResult" : [
      {
         "result" : "{hint:The result field is one of valid, invalid, notValidated, or notApplicable}valid{/hint}",
         "type" : "Validation"
      },
      {
         "result" : "notValidated",
         "type" : "CVC2"
      },
      {
         "result" : "notValidated",
         "type" : "AVS_Address"
      },
      {
         "result" : "valid",
         "type" : "MaxAuthAmount"
      },
      {
         "result" : "invalid",
         "type" : "PaymentInstrumentExpirationCheck"
      },
      {
         "result" : "notValidated",
         "type" : "AVS_PostalCode"
      },
      {
         "result" : "valid",
         "type" : "TransactionValidation"
      },
      {
         "result" : "notApplicable",
         "type" : "Screening"
      }
   ]
}

When approving or denying a transaction, you need to respond with an HTTP 200 status code.

For example, to approve a transaction, respond with an HTTP 200 status code with a message containing result authorised.

{
  "authorisationDecision" : {
    "status" : "Authorised",
  },
  "reference":"{hint:This is your unique identifier for this resource}myBalancePlatformPayment_12345{/hint}",
  "metadata":{
    "customId":"{hint:This is your unique identifier for this resource}your-own-custom-field-12345{/hint}"
  }
}

You can also include metaData object in the response, containing key-value pairs that you can use in your reporting or other business process.

To reject a transaction, respond with an HTTP 200 status code with a message containing result refused.

{
  "authorisationDecision" : {
    "status" : "Refused",
  },
  "reference":"{hint:This is your unique identifier for this resource}myBalancePlatformPayment_12345{/hint}",
  "metadata":{
    "customId":"{hint:This is your unique identifier for this resource}your-own-custom-field-12345{/hint}"
  }
}

If you do not respond within 1500 milliseconds or if you return a different HTTP status code, we will use the fallback logic you specify.

Relayed authorization fallback

When using relayed authorization, you have 1500 milliseconds to respond.

If you don't respond within 1500 milliseconds, you can specify which fallback logic you want:

• Default approval
• Default refusal

Set these rules within the Adyen Issuing dashboard.

Transaction Rules

A transactionRule is a specific limitation in how a paymentInstrument can be used. You can limit a transaction based on the amount, number of transactions, countries, MCCs, and more.

You can also combine transactions rules to represent more complex authorization logic.

Payment lifecycle

Once a payment has been attempted on a payment instrument, a balance platform payment resource is created. This resource includes information whether the payment was approved or refused. You will receive a notification webhook of the payment creation.

Each payment has a payment lifecycle which includes multiple stages such as captured, refunded, and disputed. Each stage will have a corresponding resource and update the original payment's status.