chartletv0.21.0chartlet.casoon.de

← All examples

Checkout and the interfaces it relies on

A checkout and the interfaces it relies on. Orders, Payments and the card processor list what they provides, each drawn as a ball on a stem with its label; a connection with toInterface ends in a socket around that ball, so Support visibly requires the Refunds API rather than Payments as a whole. The description and the table say it in words — “requires Payments API”, a Provides column. With a phone variant. Illustrative values.

Checkout and the interfaces it relies on

examples/payment-interfaces.json
{
  "schemaVersion": 1,
  "type": "architecture",
  "title": "Checkout and the interfaces it relies on",
  "source": "Platform handbook, payment path",
  "width": 960,
  "height": 760,
  "mobile": {
    "width": 360,
    "height": 1000
  },
  "architecture": {
    "boundaries": [
      {
        "id": "shop",
        "label": "Shop platform"
      }
    ],
    "components": [
      {
        "id": "shopper",
        "label": "Shopper",
        "kind": "person"
      },
      {
        "id": "web",
        "label": "Web shop",
        "kind": "frontend"
      },
      {
        "id": "checkout",
        "label": "Checkout",
        "in": "shop"
      },
      {
        "id": "support",
        "label": "Support",
        "in": "shop"
      },
      {
        "id": "orders",
        "label": "Orders",
        "in": "shop",
        "provides": [
          {
            "id": "orders-api",
            "label": "Orders API"
          }
        ]
      },
      {
        "id": "payments",
        "label": "Payments",
        "in": "shop",
        "provides": [
          {
            "id": "payments-api",
            "label": "Payments API"
          },
          {
            "id": "refunds-api",
            "label": "Refunds API"
          }
        ]
      },
      {
        "id": "db",
        "label": "Order store",
        "kind": "database",
        "in": "shop"
      },
      {
        "id": "psp",
        "label": "Card processor",
        "kind": "external",
        "provides": [
          {
            "id": "card-api",
            "label": "Card API"
          }
        ]
      }
    ],
    "connections": [
      {
        "from": "shopper",
        "to": "web",
        "label": "buys"
      },
      {
        "from": "web",
        "to": "checkout",
        "label": "submits",
        "technology": "HTTPS"
      },
      {
        "from": "checkout",
        "to": "orders",
        "toInterface": "orders-api",
        "label": "places"
      },
      {
        "from": "checkout",
        "to": "payments",
        "toInterface": "payments-api",
        "label": "charges"
      },
      {
        "from": "support",
        "to": "payments",
        "toInterface": "refunds-api",
        "label": "refunds"
      },
      {
        "from": "payments",
        "to": "psp",
        "toInterface": "card-api",
        "technology": "HTTPS"
      },
      {
        "from": "orders",
        "to": "db",
        "technology": "SQL"
      }
    ],
    "mainPath": [
      "shopper",
      "web",
      "checkout",
      "payments",
      "psp"
    ],
    "orientation": "portrait"
  }
}
Focus
Checkout and the interfaces it relies on
Checkout and the interfaces it relies onArchitecture diagram with 8 components and 7 connections in 1 boundary. Shop platform: Checkout, Support, Orders, Payments, Order store. Main path: Shopper → Web shop → Checkout → Payments → Card processor. Most connected: Checkout and Payments (3 connections each). Nothing leads into Shopper and Support. Nothing leads out of Order store and Card processor. Bottleneck: Checkout; without it the diagram falls apart. Shopper (person): connects to Web shop (buys). Web shop (frontend): connects to Checkout (submits, via HTTPS). Checkout (service): connects to Orders (requires Orders API, places) and Payments (requires Payments API, charges). Support (service): connects to Payments (requires Refunds API, refunds). Orders (service): connects to Order store (via SQL). Payments (service): connects to Card processor (requires Card API, via HTTPS). Order store (database): no outgoing connection. Card processor (external system): no outgoing connection. Orders provides Orders API. Payments provides Payments API and Refunds API. Card processor provides Card API.Shop platformShopper → Web shop: buysWeb shop → Checkout: submits [HTTPS]Checkout → Orders API: placesCheckout → Payments API: chargesSupport → Refunds API: refundsPayments → Card API: [HTTPS]Orders → Order store: [SQL]buyssubmits[HTTPS]placeschargesrefunds[HTTPS][SQL]ShopperShopperWeb shopWeb shopCheckoutCheckoutSupportSupportOrdersOrdersPaymentsPaymentsOrder storeOrder storeCard processorCard processorOrders APIOrders APIPayments APIPayments APIRefunds APIRefunds APICard APICard API
Checkout and the interfaces it relies onArchitecture diagram with 8 components and 7 connections in 1 boundary. Shop platform: Checkout, Support, Orders, Payments, Order store. Main path: Shopper → Web shop → Checkout → Payments → Card processor. Most connected: Checkout and Payments (3 connections each). Nothing leads into Shopper and Support. Nothing leads out of Order store and Card processor. Bottleneck: Checkout; without it the diagram falls apart. Shopper (person): connects to Web shop (buys). Web shop (frontend): connects to Checkout (submits, via HTTPS). Checkout (service): connects to Orders (requires Orders API, places) and Payments (requires Payments API, charges). Support (service): connects to Payments (requires Refunds API, refunds). Orders (service): connects to Order store (via SQL). Payments (service): connects to Card processor (requires Card API, via HTTPS). Order store (database): no outgoing connection. Card processor (external system): no outgoing connection. Orders provides Orders API. Payments provides Payments API and Refunds API. Card processor provides Card API.Shop platformShopper → Web shop: buysWeb shop → Checkout: submits [HTTPS]Checkout → Orders API: placesCheckout → Payments API: chargesSupport → Refunds API: refundsPayments → Card API: [HTTPS]Orders → Order store: [SQL]buyssubmits[HTTPS]placeschargesrefunds[HTTPS][SQL]ShopperShopperWeb shopWeb shopCheckoutCheckoutSupportSupportOrdersOrdersPaymentsPaymentsOrder storeOrder storeCard processorCardprocessorOrders APIOrders APIPayments APIPaymentsAPIRefunds APIRefundsAPICard APICard API

Source: Platform handbook, payment path

Show chart data
Data for Checkout and the interfaces it relies on
ComponentKindBoundaryProvidesConnects to
ShopperpersonWeb shop (buys)
Web shopfrontendCheckout (submits, via HTTPS)
CheckoutserviceShop platformOrders (requires Orders API, places), Payments (requires Payments API, charges)
SupportserviceShop platformPayments (requires Refunds API, refunds)
OrdersserviceShop platformOrders APIOrder store (via SQL)
PaymentsserviceShop platformPayments API, Refunds APICard processor (requires Card API, via HTTPS)
Order storedatabaseShop platform
Card processorexternal systemCard API
  • Architecture diagram with interfaces
  • Show which interface a call depends on