콘텐츠로 건너뛰기

개요

  • 버전: 2.0.0
  • 서버: https://store.xsolla.com/api
  • 이메일로 문의하기
  • 연락처 URL: https://xsolla.com/
  • 필수 TLS 버전: 1.2

카탈로그 API를 통해 엑솔라 측 인게임 아이템에 대한 카탈로그를 구성하고 스토어 사용자에게 카탈로그를 표시합니다.

API를 통해 다음 카탈로그 엔터티를 관리할 수 있습니다:

  • 가상 아이템 - 무기, 스킨, 부스터와 같은 인게임 아이템.
  • 인게임 재화 - 가상 아이템을 구매하는 데 사용되는 가상 화폐.
  • 인게임 재화 패키지 - 사전 정의된 인게임 재화 번들.
  • 번들 - 가상 아이템, 통화 또는 단일 SKU로 판매되는 게임 키의 결합 패키지.
  • 게임 키 - Steam이나 기타 DRM 제공업체와 같은 플랫폼을 통해 배포되는 게임 및 DLC의 키.
  • 그룹 - 카탈로그 내 아이템을 정리하고 분류하기 위한 로직 그룹.

API 호출

API는 다음 그룹으로 구분됩니다:

  • Admin - 카탈로그 아이템 및 그룹 생성, 업데이트, 삭제 및 구성을 위한 호출. 상품 또는 프로젝트 자격 증명으로 기본 액세스 인증을 통해 인증됩니다. 스토어프런트 용도로 사용되지 않습니다.
  • Catalog - 아이템 검색 및 최종 사용자를 위한 맞춤형 스토어프론트 구축을 위한 호출. 높은 부하 시나리오를 처리하도록 설계되었습니다. 사용자별 한도나 진행 중인 프로모션과 같은 개인화된 데이터를 반환하기 위해 선택적 사용자 JWT 인증을 지원합니다.

인증

API 호출은 사용자 또는 프로젝트를 대신하여 인증이 필요합니다. 사용된 인증 체계는 각 호출 설명의 보안 섹션에 명시되어 있습니다.

사용자의 JWT를 사용한 인증

사용자의 JWT 인증은 브라우저, 모바일 애플리케이션 또는 게임에서 요청이 전송될 때 사용됩니다. 기본적으로 XsollaLoginUserJWT 체계가 적용됩니다. 토큰 생성 방법에 대한 자세한 내용은 엑솔라 로그인 API 문서를 참조하십시오.

토큰은 다음 형식으로 Authorization 헤더에 전달됩니다: Authorization: Bearer <user_JWT>, 여기에서 <user_JWT>는 사용자 토큰입니다. 이 토큰은 사용자를 식별하고 개인화된 데이터에 대한 액세스를 제공합니다.

또는 결제 UI를 여는 토큰을 사용할 수 있습니다.

기본 HTTP 인증

기본 HTTP 인증은 서버 간 상호작용에 사용되며, API 호출이 사용자의 브라우저나 모바일 애플리케이션이 아닌 서버에서 직접 전송될 때 사용됩니다. 일반적으로 API 키를 사용한 HTTP 기본 인증이 사용됩니다.

참고

API 키는 기밀이며 클라이언트 애플리케이션에 저장하거나 사용해서는 안 됩니다.

기본 서버 측 인증을 사용하면 모든 API 요청에 다음 헤더를 포함해야 합니다:

  • basicAuth의 경우 - Authorization: Basic <your_authorization_basic_key>, 여기에서 your_authorization_basic_key는 Base64로 인코딩된 project_id:api_key 쌍입니다.
  • basicMerchantAuth의 경우 - Authorization: Basic <your_authorization_basic_key>, 여기에서 your_authorization_basic_key는 Base64로 인코딩된 merchant_id:api_key 쌍입니다.

관리자 페이지에서 매개 변수 값을 찾을 수 있습니다:

  • merchant_id는 다음 위치에 표시됩니다:
    • Company settings > Company에서.
    • 관리자 페이지의 모든 페이지에서 브라우저 주소 표시줄의 URL에. URL 형식은 다음과 같습니다: https://publisher.xsolla.com/<merchant_id>.
  • project_id는 다음 위치에 표시됩니다:
    • 관리자 페이지에서 프로젝트 이름 옆.
    • 관리자 페이지에서 프로젝트 작업 시 브라우저 주소 표시줄의 URL. URL 형식은 다음과 같습니다: https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.
  • api_key는 생성 시에만 관리자 페이지에 표시되며 귀하의 측에서 안전하게 저장해야 합니다. API 키는 다음 섹션에서 생성할 수 있습니다:
알림

필수 API 호출에 project_id 경로 매개 변수가 포함되지 않은 경우, 모든 회사 프로젝트에 대해 유효한 API 키를 사용하여 인증하십시오.

API 키 작업에 대한 자세한 내용은 API 참조 문서를 참조하십시오.

게스트 액세스 지원을 통한 인증

AuthForCart 인증 체계는 장바구니 구매에 사용되며 두 가지 모드를 지원합니다.

  1. 사용자의 JWT를 사용한 인증. 토큰은 다음 형식으로 Authorization 헤더에 전달됩니다: Authorization: Bearer <user_JWT>, 여기에서 <user_JWT>는 사용자 토큰입니다. 이 토큰은 사용자를 식별하고 개인화된 데이터에 대한 액세스를 제공합니다. 또한, 결제 UI 열기 위한 토큰을 사용할 수 있습니다.

  2. Simplified mode without Authorization header. 이 모드는 미인증 사용자만 사용하며, 게임 키 판매에만 적용할 수 있습니다. 토큰 대신 요청에 다음 헤더를 포함해야 합니다.

    • 요청 ID와 x-unauthorized-id
    • Base64로 인코딩된 사용자의 이메일 주소와 x-user

핵심 엔티티 구조

모든 유형의 아이템(가상 아이템, 번들, 인게임 재화, 키)은 유사한 데이터 구조를 사용합니다. 기본 구조를 이해하면 API 작업이 간소화되고 문서를 더 쉽게 탐색할 수 있습니다.

참고

일부 호출에는 추가 입력란이 포함될 수 있지만 기본 구조는 변경되지 않습니다.

식별

  • merchant_id- 관리자 페이지의 회사 ID
  • project_id - 관리자 페이지의 프로젝트 ID
  • sku - 프로젝트 내의 고유한 아이템 SKU

Store display

  • name - 아이템 이름
  • description - 아이템 설명
  • image_url - 이미지 URL
  • is_enabled - 아이템 가용성
  • is_show_in_store - 카탈로그에 아이템이 표시되는지 여부

카탈로그에서 아이템 가용성 관리에 대한 자세한 정보는 문서를 참조하세요.

Organization

  • type - 아이템 유형, 예를 들어 가상 아이템(virtual_item) 또는 번들(bundle)
  • groups - 아이템이 속한 그룹
  • order - 카탈로그 내 디스플레이 순서

판매 조건

  • prices - 실제 화폐 또는 인게임 재화로 된 가격
  • limits - 구매 한도
  • periods - 가용 기간
  • regions - 지역 제한

핵심 엔티티 구조 예시:

{
  "attributes": [],
  "bundle_type": "virtual_currency_package",
  "content": [
    {
      "description": {
        "en": "Main in-game currency"
      },
      "image_url": "https://.../image.png",
      "name": {
        "en": "Crystals",
        "de": "Kristalle"
      },
      "quantity": 500,
      "sku": "com.xsolla.crystal_2",
      "type": "virtual_currency"
    }
  ],
  "description": {
    "en": "Crystals x500"
  },
  "groups": [],
  "image_url": "https://.../image.png",
  "is_enabled": true,
  "is_free": false,
  "is_show_in_store": true,
  "limits": {
    "per_item": null,
    "per_user": null,
    "recurrent_schedule": null
  },
  "long_description": null,
  "media_list": [],
  "name": {
    "en": "Medium crystal pack"
  },
  "order": 1,
  "periods": [
    {
      "date_from": null,
      "date_until": "2020-08-11T20:00:00+03:00"
    }
  ],
  "prices": [
    {
      "amount": 20,
      "country_iso": "US",
      "currency": "USD",
      "is_default": true,
      "is_enabled": true
    }
  ],
  "regions": [],
  "sku": "com.xsolla.crystal_pack_2",
  "type": "bundle",
  "vc_prices": []
}

기본 구매 흐름

엑솔라 API를 사용하면 아이템 카탈로그 검색, 장바구니 관리, 주문 생성 및 상태 추적을 포함한 인게임 스토어 로직을 구현할 수 있습니다. 통합 시나리오에 따라 API 호출은 AdminCatalog 하위 섹션으로 구분되며, 서로 다른 인증 방식을 사용합니다.

다음 예시는 아이템 생성부터 구매까지 스토어 설정 및 운영을 위한 기본 흐름을 보여줍니다.

아이템 및 그룹 생성(관리자)

가상 아이템, 번들, 인게임 재화와 같은 스토어의 아이템 카탈로그를 생성합니다.

예시 API 호출:

프로모션, 체인 및 한도 설정(관리자)

할인, 보너스, 일일 보상 또는 혜택 체인과 같은 사용자 획득 및 수익화 도구를 구성합니다.

예시 API 호출:

아이템 정보 가져오기(클라이언트)

애플리케이션에서 아이템 디스플레이를 구성합니다.

알림

사용자 카탈로그를 구축하는 데 관리자 하위 섹션의 API 호출을 사용하지 마십시오. 이러한 API 호출에는 속도 제한이 있으며 사용자 트래픽을 위한 것이 아닙니다.

API 호출 예시:

참고

기본적으로 카탈로그 API 호출은 요청 시점에 스토어에서 현재 사용 가능한 아이템을 반환합니다. 아직 사용 가능하지 않거나 더 이상 사용 가능하지 않은 아이템을 검색하려면 카탈로그 요청에 "show_inactive_time_limited_items": 1 매개 변수를 포함하십시오.

아이템 판매

다음 방법을 사용하여 아이템을 판매할 수 있습니다:

  • 빠른 구매 - 하나의 SKU를 여러 번 판매합니다.
  • 장바구니 구매 - 사용자가 장바구니에 아이템을 추가하고, 제거하고, 수량을 업데이트합니다.

아이템이 실제 돈 대신 인게임 재화로 구매된 경우, 인게임 재화로 구매한 특정 아이템으로 주문 생성 API 호출을 사용하십시오. 결제 UI는 필요하지 않으며, API 호출이 실행될 때 청구가 처리됩니다.

무료 아이템 구매의 경우, 특정 무료 아이템으로 주문 생성 API 호출 또는 무료 장바구니로 주문 생성 API 호출을 사용하십시오. 결제 UI는 필요하지 않으며, 주문은 즉시 done 상태로 설정됩니다.

빠른 구매

클라이언트 측 API 호출을 사용하여 특정 아이템으로 주문 생성을 수행합니다. 호출은 결제 UI를 열기 위한 토큰을 반환합니다.

참고

할인 정보는 결제 UI에서만 사용자에게 제공됩니다. 프로모션 코드는 지원되지 않습니다.

장바구니 구매

장바구니 설정 및 구매는 클라이언트 또는 서버 측에서 수행할 수 있습니다.

클라이언트에서 장바구니 설정 및 구매

아이템 추가 및 제거 로직을 직접 구현하십시오. 장바구니 설정을 위한 API 호출 전에는 구매에 적용될 프로모션에 대한 정보를 알 수 없습니다. 이는 총 비용과 추가 보너스 아이템의 세부 사항을 알 수 없음을 의미합니다.

다음 장바구니 로직을 구현하십시오:

  1. 플레이어가 장바구니를 채운 후, 아이템으로 장바구니 채우기 API 호출을 사용하십시오. 호출은 선택한 아이템에 대한 현재 정보를 반환합니다 (할인 전후 가격, 보너스 아이템).
  2. 사용자 작업에 따라 장바구니 내용을 업데이트하십시오:
참고

현재 장바구니 상태를 얻으려면 현재 사용자의 장바구니 가져오기 API 호출을 사용하십시오.
  1. 현재 장바구니의 모든 아이템으로 주문 생성 API 호출을 사용하십시오. 호출은 주문 ID와 결제 토큰을 반환합니다. 새로 생성된 주문은 기본적으로 new 상태로 설정됩니다.

서버에서 장바구니 설정 및 구매

이 설정 옵션은 장바구니 설정에 더 많은 시간이 걸릴 수 있습니다. 장바구니의 각 변경 사항은 API 호출을 동반해야 하기 때문입니다.

다음 장바구니 로직을 구현하십시오:

  1. 플레이어가 장바구니를 채운 후, 아이템으로 장바구니 채우기 API 호출을 사용하십시오. 호출은 선택한 아이템에 대한 현재 정보를 반환합니다(할인 전후 가격, 보너스 아이템).
  2. 현재 장바구니의 모든 아이템으로 주문 생성 API 호출을 사용하십시오. 호출은 주문 ID와 결제 토큰을 반환합니다. 새로 생성된 주문은 기본적으로 new 상태로 설정됩니다.

결제 UI 열기

반환된 토큰을 사용하여 새 창에서 결제 UI를 엽니다. 결제 UI를 여는 다른 방법은 문서에 설명되어 있습니다.

작업엔드포인트
프로덕션 환경에서 열기.https://secure.xsolla.com/paystation4/?token={token}
샌드박스 모드에서 열기.https://sandbox-secure.xsolla.com/paystation4/?token={token}
참고

개발 및 테스트 중에는 샌드박스 모드를 사용하세요. 테스트 구매는 실제 계정에 청구되지 않습니다. 테스트 은행 카드를 사용할 수 있습니다.

첫 번째 실제 결제가 이루어진 후에는 엄격한 샌드박스 결제 정책이 적용됩니다. 샌드박스 모드에서의 결제는 관리자 페이지 > 회사 설정 > 사용자에 지정된 사용자에게만 가능합니다.

실제 통화로 인게임 재화와 아이템을 구매하려면 엑솔라와의 라이선스 계약을 체결해야 합니다. 이를 위해 관리자 페이지에서 Agreements & Taxes > Agreements으로 이동하여 계약 양식을 작성하고 확인을 기다리세요. 계약 검토에는 최대 3영업일이 소요될 수 있습니다.

샌드박스 모드를 활성화하거나 비활성화하려면 빠른 구매 및 장바구니 구매 요청에서 sandbox 매개 변수의 값을 변경하세요. 기본적으로 샌드박스 모드는 꺼져 있습니다.

가능한 주문 상태:

  • new - 주문 생성됨
  • paid - 결제 완료됨
  • done - 아이템 전달됨
  • canceled - 주문 취소됨
  • expired -주문 만료됨

다음 방법 중 하나를 사용하여 주문 상태를 추적하세요:

페이지 매김

대량의 레코드를 반환하는 API 호출(예: 카탈로그 작성 시)은 데이터를 페이지 단위로 반환합니다. 페이지 매김은 단일 API 응답에서 반환되는 항목 수를 제한하고 이후 페이지를 순차적으로 검색할 수 있는 메커니즘입니다.

반환되는 아이템 수를 제어하기 위해 다음 매개 변수를 사용하세요:

  • limit - 페이지당 항목 수
  • offset - 페이지의 첫 번째 항목의 인덱스(번호는 0부터 시작)
  • has_more - 다른 페이지가 있는지 여부를 나타냄
  • total_items_count - 총 항목 수

요청 예시:

GET /items?limit=20&offset=40

응답 예시:

{
  "items": [...],
  "has_more": true,
  "total_items_count": 135
}

응답이 has_more = false를 반환할 때까지 후속 요청을 보내는 것이 좋습니다.

날짜 및 시간 형식

날짜 및 시간 값은 ISO 8601 형식으로 전달됩니다.

다음이 지원됩니다:

  • UTC 오프셋
  • 항목 표시 시간 제한이 없는 경우 null
  • 일부 입력란에서 사용되는 Unix 타임스탬프(초 단위)

형식: YYYY-MM-DDTHH:MM:SS±HH:MM

예시: 2026-03-16T10:00:00+03:00

현지화

엑솔라는 항목 이름 및 설명과 같은 사용자 대상 입력란의 현지화를 지원합니다. 현지화된 값은 언어 코드를 키로 사용하는 개체로 전달됩니다. 지원되는 언어의 전체 목록은 문서에서 확인할 수 있습니다.

Supported fields

다음 매개 변수에 대해 현지화를 지정할 수 있습니다:

  • name
  • description
  • long_description

Locale format

로케일 키는 다음 형식 중 하나로 지정할 수 있습니다:

  • 두 글자 언어 코드: en, ru
  • 다섯 글자 언어 코드: en-US, ru-RU, de-DE

Examples

두 글자 언어 코드 예시:

{
  "name": {
    "en": "Starter Pack",
    "ru": "Стартовый набор"
  }
}

다섯 글자 언어 코드 예시:

{
  "description": {
    "en-US": "Premium bundle",
    "de-DE": "Premium-Paket"
  }
}

오류 응답 형식

오류가 발생하면, API는 HTTP 상태와 JSON 응답 본문을 반환합니다. 스토어 관련 오류의 전체 목록은 문서에서 확인할 수 있습니다.

Response example:

{
  "errorCode": 1102,
  "errorMessage": "Validation error",
  "statusCode": 422,
  "transactionId": "c9e1a..."
}
  • errorCode - 오류 코드.
  • errorMessage - 짧은 오류 설명.
  • statusCode - HTTP 응답 상태.
  • transactionId - 요청 ID. 일부 경우에만 반환됩니다.
  • errorMessageExtended - 요청 매개 변수와 같은 추가 오류 세부 정보. 일부 경우에만 반환됩니다.

Extended response example:

{
  "errorCode": 7001,
  "errorMessage": "Chain not found",
  "errorMessageExtended": {
    "chain_id": "test_chain_id",
    "project_id": "test_project_id",
    "step_number": 2
  },
  "statusCode": 404
}

Common HTTP status codes

  • 400 - 잘못된 요청
  • 401 - 인증 오류
  • 403 - 권한 부족
  • 404 - 리소스를 찾을 수 없음
  • 422 - 유효성 검사 오류
  • 429 - 속도 제한 초과

Recommendations

  • HTTP 상태와 응답 본문을 함께 처리하세요.
  • errorCode를 사용하여 애플리케이션 로직과 관련된 오류를 처리하세요.
  • transactionId를 사용하여 오류 분석 시 요청을 더 빠르게 식별하세요.
OpenAPI 설명 다운로드
언어
서버
https://store.xsolla.com/api/
Mock server
https://xsolla.redocly.app/_mock/ko/api/catalog/

개요

가상 아이템과 인게임 재화를 사용하여 인게임 스토어를 구축하고 사용자에게 어떻게 디스플레이할지를 구성할 수 있습니다. 다음과 같은 아이템 유형이 제공됩니다:

  • 가상 아이템 - 무기, 스킨, 부스터와 같은 인게임 상품. 실제 돈이나 가상 머니로 판매할 수 있습니다.
  • 가상 머니 - 가상 아이템을 구매하는 데 사용되는 인게임 화폐. 실제 돈이나 인게임 재화로 판매할 수 있습니다.
  • 인게임 재화 패키지 - 고정된 양의 인게임 재화. 실제 돈이나 인게임 재화로 판매할 수 있습니다.

그룹은 카탈로그에서 아이템을 구성하는 데 사용됩니다. 아이템을 논리적으로 그룹화하고 디스플레이 방식을 관리할 수 있습니다.

Admin 하위 섹션의 API 호출을 사용하여 아이템을 생성, 업데이트 및 삭제하세요.

Catalog 하위 섹션의 API 호출을 사용하여 아이템 목록을 검색하고 사용자에게 디스플레이하세요.

알림

스토어 카탈로그를 작성하는 데 Admin 하위 섹션의 API 호출을 사용하지 마세요.

참고

가상 아이템 목록 가져오기 API 호출은 가격 및 특성을 포함한 자세한 아이템 데이터를 반환하며, 페이지 매김을 지원합니다. 스토어프론트에서 카탈로그 페이지를 표시하는 데 사용하세요.

모든 가상 아이템 목록 가져오기 API 호출은 페이지 매김 없이 아이템 SKU, 이름, 설명, 그룹 ID 및 이름을 반환합니다. 클라이언트 측 검색 또는 색인에 사용하세요.

인게임 재화로 구매할 경우, 인게임 재화로 구매한 지정된 아이템으로 주문 생성 API 호출을 사용하세요. 결제 UI는 필요하지 않으며, API 호출이 실행될 때 청구가 처리됩니다.

인게임 재화를 사용한 구매 절차 예시:

인게임 재화를 사용한 구매 절차 예시

작업
작업
작업

개요

Game keys are single-use unique alphanumeric codes that grant users access to a game or DLC on gaming platforms. You can sell game keys via a direct link, through the store UI, or via a widget. You can also configure regional restrictions to sell game keys in specific countries. For detailed information, refer to the Game keys packages section.

User authentication is not required to sell game keys — the keys are sent to the email the user specified at checkout. You can configure authentication to enable additional scenarios: personalization, purchase limits, or an entitlement system. For detailed information, refer to the How to set up authentication when selling game keys section.

Game key sales flow:

  1. Create a game using the Create game API call.
  2. Configure regional restrictions.
  3. Upload keys to a game key package using the Upload codes API call to make them available for purchase.
  4. Display the game catalog with prices for the user's region using the Get games list API call.
  5. Create an order. For a fast purchase, you can use the Create order with all items from current cart API call, passing the game key SKU. The response returns a token for opening the payment UI.
  6. Implement the opening of the payment UI to pay for the order.

To receive timely notifications about successful payments and deliver items to the user, set up order status tracking, for example, using webhooks. The keys are sent to the email the user specified at checkout, and the order moves to the done status.

Game keys

작업
작업
작업

개요

Bundles are sets of items sold as a single unit. A bundle can include virtual items, virtual currency, virtual currency packages, game keys, and other bundles. Use bundles to create starter packs, seasonal offers, and special deals.

Use the following API call groups to work with bundles:

  • Use API calls from the Admin subsection to create, update, delete bundles, and manage their visibility.
  • Use API calls from the Catalog subsection to retrieve bundles.

Purchase limits are configured via the limits object when creating or updating a bundle. For more information, refer to the Limits overview. You can also configure regional restrictions to sell items in specific countries.

Note

For detailed information on configuring bundles, refer to the Bundles section.

Bundle management scenario:

  1. Create a bundle using the Create bundle API call. To verify the created bundle, use the Get bundle API call. To retrieve all bundles in the project, use the Get list of bundles API call.
  2. If needed, use the Update bundle API call to modify the bundle content or settings.
  3. Implement bundle display logic in your storefront using the Get list of bundles, Get specified bundle, or Get list of bundles by specified group API call.
  4. Create an order using the Cart and payment section. For example, for a fast purchase you can use the Create order with specified item API call, passing the bundle SKU. The response contains a token for opening the payment UI.
  5. Implement opening the payment UI to pay for the order.
  6. Set up order status tracking, for example using webhooks, to promptly receive data on successfully paid items and grant them to the user.

Bundle management scenario

작업
작업

개요

The cart is a purchasing mechanism that enables combining multiple items into a single order. A user can buy items of any type in any quantity for real currency, as well as use promo codes.

The cart is stored on the Xsolla side. Saving the cart across sessions depends on whether the user is authorized:

  • For authorized users, the cart is linked to a specific user and is saved across sessions as long as requests are sent on behalf of the same user.

  • For unauthorized users, saving the cart depends on passing the x-unauthorized-id header. To save the cart of an unauthorized user across sessions, pass the same x-unauthorized-id in every request. This option is available only for game key sales.

You can identify the cart in two ways: automatically by user's JWT or by cart ID (cart_id).

Cart management is available both on the client side and on the server side.

On the server side, you can fill the cart with items, e.g., when restoring a user session. The following actions are available on the client side:

  • retrieve the current user's cart or a cart by ID
  • fill the cart
  • update items in the cart
  • delete items from the cart

To purchase items from the cart, the client and server calls for order creation are used.

The cart’s time to live (TTL) is 72 hours by default. If its content changes, e.g., when a new item is added, the TTL is extended.

After successful payment, the cart isn’t cleared automatically. To clear the cart, use the following client-side API calls:

Cart usage scenario:

  1. Implement a store UI where the user will select items.

  2. When the user selects items in the store, add them to the cart, e.g., using the Fill cart with items call. In the items array, you need to pass the SKUs and the required quantity of items.

  3. Implement the cart viewing UI. When the user navigates to the cart, display its contents using the Get current user's cart call. The response will return information about the final price of the items, including discounts and applied promotions.

  4. Implement the opening of the payment UI to pay for the order. For example, you can use the Create order with all items from particular cart call. The response returns a token to open the payment UI.

  5. Configure order status tracking, e.g., using webhooks, to promptly receive data about successfully paid items and grant them to the user.

Note

To implement selling items in-game and online, refer to the integration guide.

Cart and payment flow

주문 수명 주기

주문 수명 주기를 이해하면 주문을 추적)하고 아이템 배송과 같은 구매 후 로직을 올바르게 구현하는 데 도움이 됩니다.

주문은 다음 단계들을 거칩니다:

상태설명참고
new주문이 생성되었습니다. 시스템은 결제 확인을 기다리고 있습니다.거래 상태 설명은 페이 스테이션 API 문서에서 확인할 수 있습니다.
paid주문 대금이 결제되었으며(거래 상태가 done로 변경됨), 해당 아이템을 사용자에게 제공할 수 있습니다. 결제가 확인될 때까지 주문은 new 상태로 남아 있습니다.
done아이템이 사용자에게 부여됩니다. -
canceled결제가 환불됩니다. 거래 상태refunded로 변경될 때 주문이 이 상태로 이동합니다.
expired한정 아이템, 프로모션 코드 또는 프로모션에 대한 새 주문을 생성하면 해당 아이템이 포함된 기존 미결제 주문은 모두 expired 상태로 변경됩니다. 가장 최근에 주문한 상품에 대해서만 결제가 가능합니다. 사용자가 만료된 주문에 대해 비용 결제를 시도하면 2002 오류가 표시되며 결제가 실패합니다.

주문 수명 주기

참고

사용자가 결제를 완료하는 도중에 주문 상태가 expired로 변경되었으나 결제가 성공적으로 완료된 경우, 주문 상태는 expired에서 paid로 변경됩니다. 이는 결제 시 해당 주문 품목의 구매 한도를 초과하지 않는 경우에만 적용됩니다.

장바구니(클라이언트 측)

이 섹션의 호출을 사용하여 클라이언트 측에서 장바구니를 관리합니다.

작업

장바구니(서버 측)

이 섹션의 호출을 사용하여 서버 측에서 장바구니를 관리합니다.

작업

결제(클라이언트 측)

이 섹션의 호출을 사용하여 클라이언트 측에서 결제 토큰을 생성합니다.

작업

결제(서버 측)

이 섹션의 호출을 사용하여 서버 측에서 결제 토큰을 생성합니다.

작업

주문

이 섹션의 호출을 사용하여 주문에 대한 정보를 얻습니다.

작업

무료 아이템

Use calls from this section to grant free items to users.

작업

개요

구매 한도를 통해 단일 사용자 또는 모든 사용자가 구매할 수 있는 아이템 수량을 제한할 수 있습니다. 또한 예약된 한도 재설정을 구성할 수 있습니다.

한도는 엑솔라 측에 저장되며 관리자 페이지 또는 다음 API 호출의 limits 객체를 통해 개별 아이템 수준에서 구성됩니다:

한도 정보는 아이템 카탈로그를 가져오는 다음 API 호출의 items.limits 객체에 반환됩니다:

한도 그룹의 관리 하위 섹션에 있는 API 호출은 현재 한도의 상태를 검색하고 특정 사용자에 대해 업데이트할 수 있도록 합니다. 예를 들어, 퀘스트 완료 후 카운터를 재설정하거나 남은 수량을 수동으로 조정할 수 있습니다.

참고

카탈로그에서 한도를 구성하는 방법에 대한 자세한 정보는 아이템 구매 한도 섹션을 참조하세요.
작업
작업
작업
작업

카탈로그

이 API를 사용하면 모든 종류의 판매할 수 있는 아이템 또는 특정 아이템을 가져올 수 있습니다.

작업
작업
작업
작업
작업