CopycURL Copied Copy failed

#!/usr/bin/env bash
# Test AVS responses
#
# Drive an address match, a mismatch and an unavailable result through the sandbox, so your
# integration reads the AVS code off the response instead of assuming the address was checked.
#
# Every API call in this blueprint, in order. Each value a call returns is passed to the calls after
# it. A step that happens outside the API is a comment, and any failed call stops the script.

set -euo pipefail

BASE_URL="{{BASE_URL}}"
API_KEY="{{API_KEY}}"

# Sends one request and prints the response body. A failed call prints the API's answer and stops
# the script.
call() {
  local method="$1" path="$2" body="${3:-}" out
  local args=(-sS --fail-with-body -X "$method" "$BASE_URL$path" -H "api-key: $API_KEY")
  if [ -n "$body" ]; then
    args+=(-H "Content-Type: application/json" -d "$body")
  fi
  if ! out=$(curl "${args[@]}"); then
    printf '%s\n' "$out" >&2
    return 1
  fi
  printf '%s' "$out"
}

# Phase 1: Drive each response in the sandbox

# Step 1: Send a sale whose address verifies
call POST "/api/transactions" '{
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "66666" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
}' > /dev/null

# Step 2: Send a sale whose address fails to verify
call POST "/api/transactions" '{
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "33333" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
}' > /dev/null

# Step 3: Send a sale the issuer can't verify
call POST "/api/transactions" '{
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "55555" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
}' > /dev/null

# Phase 2: Read the verification codes

# Step 4: Compare the three responses
# The code is on responseData.cardValidationData.avsResponse and the text the simulator reported it
# with is on responseData.cardValidationData.avsResponseText. Every call above sent the sandbox's
# guaranteed-approval amount, so the result code was the same on all three and only the verification
# code moved. The sandbox honours 17 billing ZIP triggers in total. The full table is on the testing
# page rather than repeated here. The verification code never changes the result code, so all three
# of these approve. Whether a mismatch should refuse the payment is the merchant's policy,
# configured on the merchant's card verification settings and applied after the processor answers.
# What your integration owes the payer is a decision it can explain. Read the code, make the call on
# purpose, and treat an unavailable answer as its own case rather than folding it into the mismatch
# branch.

CopyPowerShell Copied Copy failed

# Test AVS responses
#
# Drive an address match, a mismatch and an unavailable result through the sandbox, so your
# integration reads the AVS code off the response instead of assuming the address was checked.
#
# Every API call in this blueprint, in order. Each value a call returns is passed to the calls after
# it. A step that happens outside the API is a comment, and any failed call stops the script.

$ErrorActionPreference = 'Stop'

$baseUrl = '{{BASE_URL}}'
$apiKey = '{{API_KEY}}'

# Sends one request and returns the parsed response body. A failed call stops the script.
function Invoke-BlueprintCall([string] $Method, [string] $Path, [string] $Body) {
    $arguments = @{
        Method  = $Method
        Uri     = $baseUrl + $Path
        Headers = @{ 'api-key' = $apiKey }
    }
    if ($Body) {
        $arguments.ContentType = 'application/json'
        $arguments.Body = [System.Text.Encoding]::UTF8.GetBytes($Body)
    }
    Invoke-RestMethod @arguments
}

# Phase 1: Drive each response in the sandbox

# Step 1: Send a sale whose address verifies
$body = @'
{
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "66666" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
}
'@
$null = Invoke-BlueprintCall -Method 'POST' -Path '/api/transactions' -Body $body

# Step 2: Send a sale whose address fails to verify
$body = @'
{
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "33333" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
}
'@
$null = Invoke-BlueprintCall -Method 'POST' -Path '/api/transactions' -Body $body

# Step 3: Send a sale the issuer can't verify
$body = @'
{
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "55555" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
}
'@
$null = Invoke-BlueprintCall -Method 'POST' -Path '/api/transactions' -Body $body

# Phase 2: Read the verification codes

# Step 4: Compare the three responses
# The code is on responseData.cardValidationData.avsResponse and the text the simulator reported it
# with is on responseData.cardValidationData.avsResponseText. Every call above sent the sandbox's
# guaranteed-approval amount, so the result code was the same on all three and only the verification
# code moved. The sandbox honours 17 billing ZIP triggers in total. The full table is on the testing
# page rather than repeated here. The verification code never changes the result code, so all three
# of these approve. Whether a mismatch should refuse the payment is the merchant's policy,
# configured on the merchant's card verification settings and applied after the processor answers.
# What your integration owes the payer is a decision it can explain. Read the code, make the call on
# purpose, and treat an unavailable answer as its own case rather than folding it into the mismatch
# branch.

CopyTypeScript Copied Copy failed

// Test AVS responses
//
// Drive an address match, a mismatch and an unavailable result through the sandbox, so your
// integration reads the AVS code off the response instead of assuming the address was checked.
//
// Every API call in this blueprint, in order. Each value a call returns is passed to the calls
// after it. A step that happens outside the API is a comment, and any failed call stops the script.

export {};

const baseUrl = '{{BASE_URL}}';
const apiKey = '{{API_KEY}}';

// Sends one request and returns the parsed response body. A failed call throws.
async function call(method: string, path: string, body?: unknown): Promise<any> {
  const headers: Record<string, string> = { 'api-key': apiKey };
  if (body !== undefined) {
    headers['Content-Type'] = 'application/json';
  }

  const response = await fetch(baseUrl + path, {
    method,
    headers,
    body: body === undefined ? undefined : JSON.stringify(body),
  });

  const text = await response.text();
  if (!response.ok) {
    throw new Error(`${method} ${path} answered ${response.status}: ${text}`);
  }

  return text ? JSON.parse(text) : null;
}

// Phase 1: Drive each response in the sandbox

// Step 1: Send a sale whose address verifies
await call('POST', '/api/transactions', {
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "66666" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
});

// Step 2: Send a sale whose address fails to verify
await call('POST', '/api/transactions', {
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "33333" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
});

// Step 3: Send a sale the issuer can't verify
await call('POST', '/api/transactions', {
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "55555" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
});

// Phase 2: Read the verification codes

// Step 4: Compare the three responses
// The code is on responseData.cardValidationData.avsResponse and the text the simulator reported it
// with is on responseData.cardValidationData.avsResponseText. Every call above sent the sandbox's
// guaranteed-approval amount, so the result code was the same on all three and only the
// verification code moved. The sandbox honours 17 billing ZIP triggers in total. The full table is
// on the testing page rather than repeated here. The verification code never changes the result
// code, so all three of these approve. Whether a mismatch should refuse the payment is the
// merchant's policy, configured on the merchant's card verification settings and applied after the
// processor answers. What your integration owes the payer is a decision it can explain. Read the
// code, make the call on purpose, and treat an unavailable answer as its own case rather than
// folding it into the mismatch branch.

CopyC# Copied Copy failed

// Test AVS responses
//
// Drive an address match, a mismatch and an unavailable result through the sandbox, so your
// integration reads the AVS code off the response instead of assuming the address was checked.
//
// Every API call in this blueprint, in order. Each value a call returns is passed to the calls
// after it. A step that happens outside the API is a comment, and any failed call stops the script.

using System.Text;
using System.Text.Json;

var baseUrl = "{{BASE_URL}}";
var apiKey = "{{API_KEY}}";

using var http = new HttpClient();
http.DefaultRequestHeaders.Add("api-key", apiKey);

// Sends one request and returns the parsed response body. A failed call throws.
async Task<JsonElement> CallAsync(string method, string path, string? body = null)
{
    using var request = new HttpRequestMessage(new HttpMethod(method), baseUrl + path);
    if (body is not null)
    {
        request.Content = new StringContent(body, Encoding.UTF8, "application/json");
    }

    using var response = await http.SendAsync(request);
    var json = await response.Content.ReadAsStringAsync();
    if (!response.IsSuccessStatusCode)
    {
        throw new HttpRequestException($"{method} {path} answered {(int)response.StatusCode}: {json}");
    }

    return json.Length == 0 ? default : JsonSerializer.Deserialize<JsonElement>(json);
}

// Phase 1: Drive each response in the sandbox

// Step 1: Send a sale whose address verifies
await CallAsync("POST", "/api/transactions", """
    {
      "transactionType": "Sale",
      "cardData": {
        "cardNumber": "4111111111111111",
        "nameOnCard": "Jane Doe",
        "expirationMonth": 12,
        "expirationYear": 2030,
        "billingAddress": { "zip": "66666" }
      },
      "invoiceData": {
        "amounts": { "base": 10.00, "total": 10.00 }
      }
    }
    """);

// Step 2: Send a sale whose address fails to verify
await CallAsync("POST", "/api/transactions", """
    {
      "transactionType": "Sale",
      "cardData": {
        "cardNumber": "4111111111111111",
        "nameOnCard": "Jane Doe",
        "expirationMonth": 12,
        "expirationYear": 2030,
        "billingAddress": { "zip": "33333" }
      },
      "invoiceData": {
        "amounts": { "base": 10.00, "total": 10.00 }
      }
    }
    """);

// Step 3: Send a sale the issuer can't verify
await CallAsync("POST", "/api/transactions", """
    {
      "transactionType": "Sale",
      "cardData": {
        "cardNumber": "4111111111111111",
        "nameOnCard": "Jane Doe",
        "expirationMonth": 12,
        "expirationYear": 2030,
        "billingAddress": { "zip": "55555" }
      },
      "invoiceData": {
        "amounts": { "base": 10.00, "total": 10.00 }
      }
    }
    """);

// Phase 2: Read the verification codes

// Step 4: Compare the three responses
// The code is on responseData.cardValidationData.avsResponse and the text the simulator reported it
// with is on responseData.cardValidationData.avsResponseText. Every call above sent the sandbox's
// guaranteed-approval amount, so the result code was the same on all three and only the
// verification code moved. The sandbox honours 17 billing ZIP triggers in total. The full table is
// on the testing page rather than repeated here. The verification code never changes the result
// code, so all three of these approve. Whether a mismatch should refuse the payment is the
// merchant's policy, configured on the merchant's card verification settings and applied after the
// processor answers. What your integration owes the payer is a decision it can explain. Read the
// code, make the call on purpose, and treat an unavailable answer as its own case rather than
// folding it into the mismatch branch.

CopyPython Copied Copy failed

# Test AVS responses
#
# Drive an address match, a mismatch and an unavailable result through the sandbox, so your
# integration reads the AVS code off the response instead of assuming the address was checked.
#
# Every API call in this blueprint, in order. Each value a call returns is passed to the calls after
# it. A step that happens outside the API is a comment, and any failed call stops the script.

import requests

BASE_URL = "{{BASE_URL}}"
API_KEY = "{{API_KEY}}"


# Sends one request and returns the parsed response body. A failed call raises.
def call(method, path, body=None):
    response = requests.request(
        method,
        BASE_URL + path,
        headers={"api-key": API_KEY},
        json=body,
    )
    response.raise_for_status()
    return response.json() if response.content else None


# Phase 1: Drive each response in the sandbox

# Step 1: Send a sale whose address verifies
call("POST", "/api/transactions", {
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "66666" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
})

# Step 2: Send a sale whose address fails to verify
call("POST", "/api/transactions", {
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "33333" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
})

# Step 3: Send a sale the issuer can't verify
call("POST", "/api/transactions", {
  "transactionType": "Sale",
  "cardData": {
    "cardNumber": "4111111111111111",
    "nameOnCard": "Jane Doe",
    "expirationMonth": 12,
    "expirationYear": 2030,
    "billingAddress": { "zip": "55555" }
  },
  "invoiceData": {
    "amounts": { "base": 10.00, "total": 10.00 }
  }
})

# Phase 2: Read the verification codes

# Step 4: Compare the three responses
# The code is on responseData.cardValidationData.avsResponse and the text the simulator reported it
# with is on responseData.cardValidationData.avsResponseText. Every call above sent the sandbox's
# guaranteed-approval amount, so the result code was the same on all three and only the verification
# code moved. The sandbox honours 17 billing ZIP triggers in total. The full table is on the testing
# page rather than repeated here. The verification code never changes the result code, so all three
# of these approve. Whether a mismatch should refuse the payment is the merchant's policy,
# configured on the merchant's card verification settings and applied after the processor answers.
# What your integration owes the payer is a decision it can explain. Read the code, make the call on
# purpose, and treat an unavailable answer as its own case rather than folding it into the mismatch
# branch.