[In-app Billing_0]Overview 2

@ Messaging sequence 1 [PURCHASE]

 - 아래는 메시지 시퀀스의 전형적인 요청을 보여준다.
 (sendBillingResquest()는 Bold, broadcast는 italic)

==> 결제 요청

1-1.   (발신_IPC) 사용자 애플리케이션은 구글 플레이에 구매 요청(REQUEST_PURCHASE)를 한다. 이때 PRODUCT_ID와 다른 파라미터를 함께 보낸다.

1-2.   (수신_IPC) 구글 플레이에서 번들 데이터(RESPONSE_CODE, PURCHASE_INTENT, REQUEST_ID)를 요청한 앱에 보낸다. PURCHASE_INTENT는 결제 UI를 위한 PendingIntent를 제공한다.

1-3.   (발신_UI호출)사용자 애플리케이션은 PendingIntent로 결제 UI를 실행 시킨다.
  - 단, 이때 application context가 아니라 activity context로 부터 pending intent를 실행시킨다.

==> 결제 종료 및 결제 내역 정보 요청

2.  (수신_Broadcast)결제가 끝나면(상품을 성공적으로 구매했거나 결제를 취소한 것을 의미) 구글 플레이에서 사용자 애플리케이션으로 알림 메시지(an IN_APP_NOTIFY broadcast intent)를 보낸다. 알림 메시지는 notification ID(transation과 관련된)를 포함한다.

3-1.  (발신_IPC)사용자 애플리케이션은 GET_PURCHASE_STATE_CHANGED 요청을 보내서 관련된 결제정보를 요청한다. 이때 4번에서 얻은 notification ID를 함께 보낸다.

3-2. (수신_IPC) 구글 플레이는 번들 형태(RESPONSE_CODE key, REQUEST_ID key)로 해당 결제 정보를 보내준다.

==> 결제 내역 확인 

3-3.  (수신_Broadcast)구글 플레이 TRANSATION 정보를 사용자 애플리케이션에 보낸다.(PURCHASE_STATE_CHANGED broadcast intent)

4-1. (발신_IPC)사용자 애플리케이션은  NOTIFICATION ID로 수신된 결제 정보를 확인한다. 확인후 CONFIRM_NOTIFICATIONS 를 보낸다.

4-2. (수신_IPC) 구글 플레이에서 사용자 애플리케이션에 번들(RESPONSE_CODE , REQUEST_ID를 포함한)을 보낸다.


#  당신은 결제 내역 확인 후 확인 메시지를  구글 플레이에 보내야 한다.[4-1 CONFIRM_NOTIFICATIONS] 그렇지 않으면 구글 플레이는 IN_APP_NOTIFY message를 확인 하지 않은 것으로 간주한다. 이것으로 개발자는 상품을 사용자에게 전달하기 전까지 확인 메시지를 보내지 않도록 함으로 결제의 안전성(중간에 애플리케이션이 종료되거나, 상품이 전달 되지 못하는 경우)을 높일 수 있다. 즉, 결제가 시작되고 물건이 사용자에게 전달되면, CONFIRM_NOTIFICATIONS를 구글 플레이에 보내 결제를 마무리 하도록 할 수 있다. 또한 여러 건의 구매에 경우 이러한 확인 응답은 매우 중요한 역할을 한다.(중간에 여러가지 일들이 있을수 있으므로)

@ Messaging sequence 2 [RESTORE]

-  아래는 이전에 했던 결제 내용을 확인 하는 메시지 시퀀스입니다.

(sendBillingResquest()는 Bold, broadcast는 italic)

- 이 메시지 시퀀스의 경우 한번의 요청으로 3가지 응답을 받습니다.

 1.(발신_IPC) RESTORE_TRANSATIONS 요청을 구글 플레이에 보냅니다.

 2.(수신_IPC) 구글 플레이는 RESPONSE_CODE와 REQUEST_ID를 포함한 번들을 사용자 애플리케이션에 보냅니다.

 3. (수신_Broadcast) 구글 플레이는 RESPONSE_CODE broadcast intent를 통해 요청 정보 상태에 대한 응답을 보냅니다.(정보 상태, 에러 정보등) 이때 메시지는 특정 request ID를 참조하고 있습니다.

 4. (수신_Broadcast)  구글 플레이는 또한 PURCHASE_STATE_CHANGED broadcast intent를 보냅니다. 이 응답은 요청한 결제 정보를 포함하고 있습니다. (이때 CONFIRM_NOTIFICATIONS 메시지를 보낼 필요가 없다)

# RESTORE_TRANSACTIONS 요청은 처음 사용자 애플리케이션이 설치될때나 삭제되고 다시 설치 될때 사용해야 한다.

@ Messaging sequence 3 [CHECKING]

- 아래는 결제 가능한 상태인지 알아보는  메시지 시퀀스 입니다.

(sendBillingResquest()는 Bold)

1. 사용자 애플리케이션은 구글 플레이에  CHECK_BILLING_SUPPORTED를 요청한다.


2. 구글 플레이는 번들 데이터로 사용자 애플리케이션에 응답을 한다.
 - RESULT_OK  :  결제가능 상태
 - RESULT_BILLING_UNAVAILABLE : 결제 불가 상태 (사용자가 있는 곳이 부분 결제가 되지 않는 경우..)
 - SERVER_ERROR : 구글 플레이 서버 오류

@ Handling IN_APP_NOTIFY messages

 - 아래는 IN_APP_NOTIFY 메시지의 특별한 케이스를 다룬다. 

1. Handling multiple IN_APP_NOTIFY message

 -  구글 플레이는 늘 CONFIRM_NOTIFICATIONS 메시지(PURCHASE_STATES_CHANGED에 해당하는)를 받았을 때 PURCHASE_STATES_CHANGED 메시지를 보내지 않는다. 하지만 때때로 사용자 애플리케이션이 CONFIRM_NOTIFICATIONS 메시지를 보내도 반복적으로 PURCHASE_STATES_CHANGED 메시지를 멈추지 않고 보낸다. 

  이와 같은 현상은,

  첫째로, CONFIRM_NOTIFICATION 메시지 전송중 네트워크 커낵션을 잃어버리면 일어난다.

  둘째로, 여러개의 IN_APP_NOTIFY 메시지를 보낸 경우 해당 확인 (CONFIRM_NOTIFICATIONS) 메시지를 받지 못했을 때 일어난다. 

그러므로 사용자 애플리케이션은 각 결제에 대한 IN_APP_NOTIFY를 식별해서 해당 확인 메시지를 보내야 한다. 이를 위해 JSON string에 있는 orderid를 사용하면 된다. (orderid는 모든 결제에 대해 중복되지 않는 고유한 것 아이디이다.)

2. Handling refunds and other unsolicited IN_APP_NOTIFY messages
 [ 환불 메시지 , 요청하지 않은 알림 메시지]

- REQUEST_PURCHASE 메시지를 보내지 않고 IN_APP_NOTIFY broadcast intents를 받을 수 있다.

1. 두 개의 디바이스에 사용자 애플리케이션이 설치되어 한 디바이스에서 결제 요청을 보낼때, 요청하지 않은 알림 메시지를 받을 수 있다. 이 경우 전형적인 메시지 시퀀스 요청으로 처리 할 수 있다. 단, 'managed per user account' 타입 아이템에만 지원된다.

2. 구글 체크 아웃에서 환불로 메시지를 보낼 때 요청하지 않은 알림 메시지를 받을 수 있다. 이 경우도 위와 같이 전형적인 메시지 시퀀스 요청으로 PURCHASE_STATES_CHANGED 메시지를 받을 수 있다. 여기서 포함된 JSON string을 통해 환불 상태를 확인 할 수 있다. (purchaseState ->2)

# 중요!!  : Google Checkout API를 통해 환불 요청하거나 부분 유료 결제를 취소할 수 없다. 단, 판매자 계정에서 취소시 환불 될 수 있다. Google Checkout API는 결제에 대한 정보만 검색할 수 있다.

@ Security Controls

 - 구글 플레이 결제 정보 무결성(중복방지)을 위해, PURCHASE_STATE_CHANGED의  JSON string에 사인을 넣고 있다. 이 사인을 만들기 위해 판매자의 private key를 사용한다. 판매자는 RSA key 짝(public keys)을 구글 플레이 사이트에서 생성할 수 있다.

 - 구글 플레이에서 사인한 응답을 내 RSA 키와 짝이 맞는 공개키를 사용해 식별한다. 이는 조작되거나 해킹된 정보를 식별할 수 있다. 이 확인 작업을 사용자 서비스 서버가 있다면 거기서 하기를 권장한다.

- 결제 정보에는 nonces라는 번호가 있다. 이는 유일한 랜덤 번호이다. 이를 통해 결제를 구별해 낼 수 있다. 당신의 애플리케이션은 GET_PURCHASE_INFORMATION 요청과 RESTORE_TRANSACTIONS 요청을 할때 반드시 nonce를 생성해서 보내야 한다. 구글 플레이는 이 요청을 받으면  결제에 관한  JSON  string 정보에 nonce를 넣어 응답한다. 사용자 애플리케이션은 응답을 받았을 때 사인 정보를 식별하는 것과 더불어 nonce를 확인해서 할 필요가 있다.

@in-app Billing Requirements and Limitations

# 인앱 결제를 하기 전에 다음과 같은 사항을 확인해야 한다.

1. 인앱 결제는 반드시 구글 플레이를 통해서 유통되는 애플리케이션에만 구현될 수 있다.
2. 당신은 Google Checkout Merchant account를 가지고 있어야 한다.
3. 당신의 애플리케이션이 Android 3.0 버전에서 구동된다면, in-app billing은 5.0.12 버전 이상을 필요로 하고 그외에는 2.3.4버전 이상을 필요로 한다.
4. 애플리케이션은 Android 1.6 버전 이상에서 인앱 결제를 사용할 수 있다.
5. 당신은 인앱 결제를 통해 전자 컨텐츠만 판매 할 수 있다. 물리적인 재화나 개인적인 서비스등 물리적인 전달이 필요한 어떤 것이든 판매 할수 없다.
6. 구글 플레이는 어떤 컨텐츠 배달 폼을 지원하지 않는다. 컨텐츠 배달, 전달은 사용자 애플리케이션을 판매하는 판매자에게 책임이 있다.
7. 네트워크가 연결되지 않은 상황에서 결제는 일어날수 없다. 결제완료 요청을 하기 위해서는 디바이스는 네트워크를 통해 구글 플레이 서버에 접속해야 한다.