계정 ID
계정 ID는 연결 흐름 중에 통합업체의 서버에서 다시 전송됩니다. 이 ID는 Google에서 두 가지 방법으로 기본 계정을 식별하는 데 사용됩니다. 첫째, 위험 및 사기를 평가하기 위해 동일한 기본 사용자 계정을 사용하는 여러 결제 수단을 식별합니다. 둘째, Google 고객 서비스 상담사가 이 계정을 식별하는 데 사용됩니다. 이 값은 연결 요청 전체에서 사용자 계정을 고유하게 식별해야 하고, 특정 계정에서 변경할 수 없어야 하고 사용자가 식별할 수 있어야 합니다.
예를 들어 통합업체가 ID로 이메일 주소를 사용하는 경우 이메일 주소를 사용할 수 있습니다. 통합업체가 로그인에 이메일 주소를 사용하지만 이메일 주소를 변경할 수 있는 경우, 이메일 주소를 계정 ID로 사용하는 것은 적절하지 않습니다. 어떤 옵션을 선택하든 동일한 결제 통합업체 사용자 ID로 여러 연결을 시도할 경우 값이 동일해야 합니다.
Android 애플리케이션 패키지(APK)
Android 운영체제에서 모바일 앱의 배포와 설치를 위해 사용하는 패키지 파일 형식입니다.
API 버전 관리
이 사양은 버전 관리를 지원합니다. 지원되는 버전은 Google 서버에서 구성됩니다. 버전 N에서 M으로 이동할 때 (여기서 M은 N보다 큰 주 버전이 있음) Google에서 모든 트래픽이 M으로 이전되었음을 확인할 때까지 통합업체는 N과 M을 모두 지원해야 합니다. 버전은 컨텍스트에 따라 다르게 식별됩니다. Android API 및 WebRedirect API는 API 버전을 매개변수로 요청에 전달합니다. 서버 간 호출은 해당 버전을 URL 경로의 일부로 전달합니다.
버전은 흐름에 의해 고정되지 않습니다. 따라서 N에서 M으로 이전하는 동안 통합업체는 동일한 거래에 대해 버전 M에서 캡처를 확인하고 버전 N으로 환불을 받을 수 있습니다. 연결 중에 통합자는 버전 N의 연결 요청과 함께 버전 M의 인증 요청을 받을 수 있습니다.
연결 ID
associationID는 고객 계정과 Google 결제 수단 간의 연결을 나타냅니다. associationId는 GPT와 매우 유사합니다. 실제로 전체 기간이 GPT와 같으며 GPT와 1:1 카디널리티를 가집니다. associationId의 민감도는 GPT와 다릅니다. GPT는 결제에 사용되는
민감한 토큰입니다. associationId는 동일한 관계를 나타내지만 기본적으로 민감하지 않은 공개 식별자입니다.
associationId는 associateAccount 중에 결제 통합업체에 전달됩니다. 이 동일한 값이 통합업체에 재인증하는 동안 전달됩니다. 이를 통해 통합자는 인증해야 하는 계정에 대한 컨텍스트를 파악할 수 있습니다. 연결 ID가 전달되면 원래 연결 중에 식별된 것과 동일한 계정이 미리 입력되고 인증되어야 합니다.
결제 통합업체는 통합업체와 Google 간의 계약 기간 동안 모든 연결 ID를 저장하고 특정 통합업체 계정과 연결해야 합니다.
인증 요청 ID
refreshToken, associateAccount, 캡처 메서드 (선택사항)는 인증 참조를 사용합니다. 이 참조는 Google에서 참조하는 특정 인증의 requestId 형식입니다. 이 필드는 결제 통합업체가 인증에 성공한 후 메서드가 실제로 진행되었는지 확인하는 데 사용됩니다.
캡처 메서드에는 인증 requestId를 채울 수 있습니다. 이는 두 가지 경우에 발생합니다. Google이 캡처 직전에 사용자를 인증하면 Google은 인증 requestId 필드를 채웁니다. 또한 Google은 자동 결제 일정이 설정된 설정 시점에 사용자를 인증하는 경우가 많습니다. Google은 이 일정에 인증 requestId를 기록하고 특정 일정과 관련된 모든 캡처와 함께 requestId를 전송합니다.
결제 통합업체는 모든 인증 requestIds를 30일 동안 저장해야 합니다. 결제 통합업체가 결제 일정에 포함된 항목을 포함하여 캡처 요청에 표시될 수 있는 인증 requestIds를 감사하려는 경우 통합업체는 통합업체와 Google 간의 계약 기간 동안 모든 인증 requestId를 저장해야 합니다.
회사
회사는 Google의 구성 및 계약 내에 정의된 개념입니다. 회사는 통합업체와 Google 간의 관계를 정의합니다. PGP 키 및 SSL 루트 CA(선택사항)가 회사와 연결됩니다. 가장 중요한 점은 회사가 하나 이상의 결제 통합업체 계정 ID와 연결되어 있다는 것입니다. 회사 내에서 생성된 GPT는 대부분 회사 내의 모든 결제 통합업체 계정 ID에서 작동합니다. 일부 예외가 적용됩니다. 예를 들어 GPT가 한 통화로 표시된 계정과 연결되어 있고 외환 수수료를 지원하지 않는 경우 다른 통화로 결제 통합업체 계정 ID로 구매하려는 경우입니다.
결제 수단 (FOP)
모든 거래에는 신용카드 또는 전자 송금과 같은 하나 이상의 결제 수단(FOP)이 포함됩니다. 이러한 결제 수단은 사용자가 제품 또는 서비스에 대한 비용을 Google에 지불하거나 Google에서 사용자에게 지불(애드센스 사용자 및 Google Play 개발자)하는 데 사용됩니다. 결제 수단은 결제 수단, 결제 수단, 결제 수단이라고도 합니다.
Google 결제 토큰 (GPT)
GPT는 연결 시 Google 서버에서 생성되어 통합업체 서버로 전달되는 웹에 안전한 임의의 base64 인코딩 값입니다. GPT는 사용자 계정과 통합업체 및 Google 결제 수단 간의 연결을 나타내는 비공개 식별자입니다. GPT는 사용자 인증 정보나 계정 ID를 대체하는 토큰입니다. 이 토큰은 구매 흐름 중에 신용 또는 출금할 계정을 식별하기 위해 사용되며, 양 당사자에게 공개되지 않습니다. GPT는 일반 텍스트로 전송해서는 안 되며 개인 정보 보호를 위해 암호화해야 합니다.
GPT는 associationId와 다릅니다. associationId가 보호되지 않으며 공개 수단 (URL, 안전하지 않은 연결)을 통해 자유롭게 전달되기 때문입니다. GPT는
Google과 통합업체만 알고 있습니다.
결제 통합업체는 통합업체와 Google 간의 계약 전체 기간 동안 모든 GPTS를 저장하고 특정 통합업체 계정에 연결해야 합니다.
멱등성
멱등성 작업은 결과를 변경하거나 작업의 초기 적용 이후에 새로운 부작용을 일으키지 않고 여러 번 적용할 수 있습니다. 일반적으로 멱등성은 '키'를 사용하여 동일한 요청을 식별합니다. 두 서버 간에 정의된 모든 요청은 요청 헤더에 정의된 멱등성 키를 사용합니다. 요청 헤더에는 멱등 키로 사용되는 요청 ID가 있습니다. 요청 ID는 전역적으로 고유합니다. 멱등성 요청은 JSON 본문과 정확히 동일해야 하며 한 가지 예외가 있습니다. requestTimestamp는 요청마다 다릅니다. 이것은 중요한 차이점입니다. requestTimestamp은 서버가 이 요청을 보낸 시간입니다. 그리고 시도마다 고유합니다. 이렇게 하면 재전송 공격 가능성을 줄일 수 있습니다.
마찬가지로 멱등성 응답은 JSON 본문과 정확히 같아야 합니다. 단, responseTimestamp이 응답마다 다르다는 점이 다릅니다.
에코 메서드를 제외한 모든 서버 간 메서드는 멱등성이 있어야 합니다. 통합업체의 UI (Android 또는 웹)에 대한 인증 요청은 멱등성이 없습니다.
멱등 동작의 예는 참조 문서를 확인하세요.
식별자(ID)
식별자는 결제 통합업체와 Google 간의 트랜잭션 또는 통신을 나타냅니다.
결제수단
결제 수단은 단일 Google 고객과 연결된 저장된 결제 수단을 나타냅니다. 결제 수단의 예는 다음과 같습니다.
- 등록된 신용카드 번호
- 은행 계좌 및 은행 고유번호
사용자는 Google ID와 연결된 여러 결제 수단을 사용할 수 있습니다.
마이크로
이 API의 금액은 Google의 표준인 '마이크로'라고 하는 형식으로 표시됩니다. 마이크로는 정수 기반의 고정 정밀도 형식입니다. 마이크로 단위로 금액을 나타내려면 표준 통화 값에 1,000,000을 곱합니다.
예를 들면 다음과 같습니다.
- 1.23달러 = 1230,000마이크로달러
- 미화 0.01달러 = 10,000마이크로 미화
결제 통합업체
사용자 거래의 결제를 처리하는 외부 통합업체입니다.
결제 통합업체 계정 ID
이 식별자는 Google과 통합업체 간의 계약에 관한 제약 조건을 나타냅니다. 통합업체 계정 ID는 Google에서 생성되고 설정 시간 동안 통합업체에 할당됩니다. 일반적으로 이를 'MID'라고 합니다. 모든 요청과 응답에는 이 ID가 포함되어야 합니다. 이 식별자는 불투명하며 파싱하면 안 됩니다. 이 식별자의 형식은 발급된 모든 ID에서 일관되지 않을 수 있습니다.
이 식별자는 거래의 전체 기간 동안 변경되지 않습니다. 캡처 및 환불의 경우에는 동일한 식별자가 사용됩니다.
통합업체 계정 ID의 제약 조건은 계약 자체에 의해 정의됩니다. 일반적으로 인보이스와 관련된 제한사항이 있습니다. 예를 들어 통합업체는 USD로 인보이스가 발행되는 CAD 및 MXN을 지원하지만 EUR 트랜잭션의 경우 EUR로 인보이스를 발행해야 합니다. 이 경우 두 개의 서로 다른 결제 통합자 계정 ID(USD 인보이스와 EUR 인보이스용)가 사용됩니다.
식별자는 단계적으로 중단되고 새로운 식별자로 대체될 수 있습니다. 식별자가 지원 중단되는 경우 Google은 해당 식별자에 대한 캡처 시작을 중지합니다. 하지만 통합자는 마지막 캡처 시작 (requestHeader에 있는 requestTimestamp으로 정의된 캡처 시작)으로부터 1년 동안 이 식별자로 이루어진 거래의 환불을 인정해야 합니다.
개인 식별 정보
개인 식별 정보(PII)는 개인을 식별하는 정보 및 Google에서 이러한 정보와 연관이 있다고 합리적으로 판단할 만한 기타 데이터(예: 사용자 이름, 이메일 주소, 우편 주소, 전화번호)를 단독으로 또는 조합하여 개인을 식별하는 정보입니다.
요청 ID
requestId는 Google과 결제 통합업체 간의 모든 통신을 식별합니다.
SPII
민감한 개인 식별 정보 (SPII)는 개인 식별 정보 (PII)의 하위 집합으로, 유출되거나 오용되는 경우 사용자에게 높은 위험을 초래할 수 있습니다. SPII에는 법률, 규제 또는 규정 준수 기관에서 부과하는 제한적인 처리 및 저장 요구사항이 있는 경우가 많습니다.
토큰
토큰은 PII 또는 SPII와 같은 민감한 사용자 인증 정보가 Google과 통합업체 간에 교환될 때 보안을 한층 더 강화합니다.
사용자 주소
결제 수단 생성 시 Google은 사용자가 Google Payments 고객인지 확인합니다. 이는 Google 고객과는 별개입니다. Google Payments 고객이 되려면 사용자의 청구서 수신 주소가 필요합니다. 사용자의 전체 주소를 Google에 알려달라고 요청하는 규제 기관도 있고 해당 주소의 하위 집합을 요구하는 규제 기관도 있습니다.
결제 통합업체가 이 사용자의 주소를 등록한 경우 Google은 사용자의 주소 양식을 미리 작성하기 위해 연결 흐름에서 해당 주소를 가져오려고 합니다. 사용자는 미리 입력된 주소를 변경할 수 있습니다. 사용자 주소를 미리 채우면 결제 수단을 추가할 때 발생하는 번거로움이 줄어들고 사용자가 결제 수단을 추가할 때 전환율이 높아집니다.
주소가 공유되는 경우 Google은 이 주소를 위험 모델의 계산으로도 사용합니다. 이렇게 하면 Google의 위험 엔진이 사용자가 청구 대상으로 명시한 주소를 이해하면서 사용자의 현재 IP 위치와 비교할 수 있습니다.
주소 공유는 순수한 최적화입니다. 일부 통합업체는 사용자의 청구서 수신 주소가 없거나 이 주소를 공유할 수 없는 것이 정상입니다.
웹에 적합한 Base64 인코딩
RFC 4648 섹션 5, URL 및 파일 이름 안전 알파벳을 사용한 Base64 인코딩에 지정된 인코딩 표준으로, '웹 안전 Base64' 또는 'base64url' 인코딩이라고도 합니다. (이는 RFC 3548 섹션 4의 URL 및 파일 이름 안전 알파벳을 사용하는 base64 인코딩과 동일합니다.) 모든 암호화 및 부호 있는 값은 이 표준을 사용하여 인코딩되어야 합니다.