begin_personal_payment

Người yêu cầu bắt đầu thanh toán phần của mình — personal_amount, phần còn lại sau khi trừ phần công ty trả. API trả về một extra purchase mà store service sẽ trừ vào ví của người yêu cầu. Khi store báo đã thanh toán, yêu cầu chuyển từ AWAITING_PERSONAL_PAYMENT sang CONFIRMED trong luồng trạng thái.

Đây là một GraphQL mutation trả về ExtraPurchase. Chỉ người tạo yêu cầu mới gọi được, và chỉ khi yêu cầu đang ở AWAITING_PERSONAL_PAYMENT.

Input

input: BeginPersonalPaymentInput!

Trường	Kiểu	Bắt buộc	Mô tả
user_request_id	String	Có	User request cần thanh toán.

Response

Trường	Kiểu	Mô tả
id	String	Extra purchase cần thanh toán. Gửi lên book_extra_purchase của store.
amount	Decimal	Số tiền người yêu cầu trả: personal_amount, đổi sang VND.
currency	String	Luôn là VND.
status	ExtraPurchaseStatus	PAYING cho đến khi store báo kết quả thanh toán.

Gọi lại khi khoản thanh toán vẫn đang PAYING sẽ trả về đúng extra purchase đó — nên nếu người yêu cầu rời checkout mà chưa trả, hãy book lại chính khoản đó. Sau khi một lần thanh toán thất bại, lần gọi tiếp theo sẽ tạo khoản mới. Mỗi lần thử là một extra purchase riêng, mang user_request_id của yêu cầu và personal: true; mỗi lúc chỉ có tối đa một khoản PAYING.

Mutation

mutation {
  begin_personal_payment(input: { user_request_id: "3JMY..." }) {
    id amount currency status
  }
}

Thanh toán trong store

FE gọi begin_personal_payment, rồi book_extra_purchase của store, rồi hoàn tất bằng Payment Flow của store — xem Người yêu cầu thanh toán thế nào.

1. begin_personal_payment (flight) — trả về extra purchase.
2. book_extra_purchase (store), với input: { flight: { id: "<id của extra purchase>" } } — đưa nó vào giỏ của người yêu cầu. Chỉ người yêu cầu mới book được khoản thanh toán cá nhân của chính mình. Bước 1–2 chính là bước 3 của Payment Flow, "create shopping_item": hãy xóa giỏ hàng và hủy checkout session còn mở trước.
3. Phần còn lại của Payment Flow (store) — begin_payment_checkout_session, để tắt thanh toán công ty (đây là tiền của chính người yêu cầu, không phải của công ty), rồi pay_with_wallet.
4. Store tự báo cho flight service khi thanh toán thành công hoặc thất bại; không cần gọi gì thêm. Khi thành công, yêu cầu chuyển sang CONFIRMED, rồi tới bước phê duyệt, hoặc thẳng sang RESOLVED khi công ty không trả gì. Khi thất bại, yêu cầu vẫn ở AWAITING_PERSONAL_PAYMENT, và người yêu cầu có thể bắt đầu lại từ bước 1.

Hãy fetch lại yêu cầu sau khi thanh toán, trước khi hiển thị trạng thái.

Mã lỗi

Mã lỗi	Ý nghĩa
<status>_user_request	Yêu cầu không ở AWAITING_PERSONAL_PAYMENT — ví dụ resolved_user_request khi đã thanh toán xong.
no_personal_amount	Người yêu cầu không còn gì phải trả.
personal_payment_in_progress	Một lần gọi khác vừa bắt đầu thanh toán cùng lúc, và khoản đó đã kết thúc trước khi lần gọi này kịp trả về. Hãy gọi lại.
unauthorized	Người gọi không phải người tạo yêu cầu.
not_found	user_request_id không tồn tại.

book_extra_purchase của store có thêm hai mã lỗi riêng:

Mã lỗi	Ý nghĩa
unauthorized	Người khác (không phải người yêu cầu) cố book khoản thanh toán cá nhân.
<STATUS>_extra_purchase	Extra purchase không còn ở PAYING — ví dụ CANCELLED_extra_purchase. Gọi lại begin_personal_payment để lấy khoản mới.

API này cũng có thể trả về Lỗi middleware. Mọi mã lỗi của user request được liệt kê chung trong Lỗi của User Request.