Skip to main content

add_passenger_fee

Adds a seat, baggage or other fee to one passenger on one leg and charges it. With user_request_id and user_request_fee_id, it is also how an admin applies a fee of a RESOLVED user request — the last step of the user request flow. Each fee of a request is applied with its own call.

It is a GraphQL mutation returning Passenger, and needs the ADMIN role.

Input​

input: AddPassengerFeeInput!

FieldTypeRequiredDescription
booking_history_idStringYesThe booking to add the fee to.
fee_typeFeeTypeYesBAGGAGE, SEAT or OTHER. With a user request fee, it must be that fee's type.
departure_eticket_idStringOne of the twoThe passenger's e-ticket on the departure leg.
arrival_eticket_idStringOne of the twoThe passenger's e-ticket on the return leg.
baggageAddBaggageInputWhen BAGGAGE, without a user requestThe baggage to add.
seatSeatInputWhen SEAT, without a user requestThe seat to add.
other_feeOtherFeeInputWhen OTHER, without a user requestThe fee to add.
user_request_idStringNoA RESOLVED user request whose fee this applies. Needs user_request_fee_id.
user_request_fee_id newStringWith user_request_idThe fee of that request to apply. Each fee can be applied once.

The e-ticket picks both the passenger and the leg. If both are sent, the departure one is used.

Applying a user request fee​

The fee is accepted only when all of these hold:

  • The request is RESOLVED.
  • It belongs to the same booking as booking_history_id, and is for the same passenger as the e-ticket.
  • The fee is one of the request's fees, isn't paid yet, and is for the e-ticket's leg.
  • fee_type is the fee's type.

With it, the call behaves differently:

Without a user requestWith a user request fee
Seat / baggage / other fee dataRequired; decides what is addedTaken from the fee; the input's baggage, seat and other_fee are ignored
Charged to the companyThe fee priceThe fee's corporate_amount, converted to VND (0 means no charge)
Booking price goes up byThe fee priceThe fee's full price
AfterwardsNothing newThe fee is paid, and the payment is added to its extra_purchase_ids

The requester's part (price - corporate_amount) was already paid with begin_personal_payment, before approval.

Mutation
mutation {
add_passenger_fee(input: {
booking_history_id: "..."
fee_type: SEAT
departure_eticket_id: "..."
user_request_id: "3JMY..."
user_request_fee_id: "3Jwm...seat"
}) { id }
}

When the payment fails​

If the payment is refused, the fee stays unpaid and the admin can retry. The store service's own error comes back, such as not_enough when the corporate balance is too low.

If the payment service can't be reached, the call returns payment_unreachable and the fee stays marked as paid, because the charge may have gone through. Check with the backend team before retrying.

Errors​

Errors for a user request fee:

ErrorMeaning
user_request_not_foundUnknown user_request_id.
<status>_user_requestThe request isn't RESOLVED — for example confirmed_user_request.
user_request_fee_id_requireduser_request_id was sent without user_request_fee_id.
user_request_fee_not_foundThe fee isn't one of the request's fees.
paid_user_request_feeThe fee was already applied.
user_request_fee_type_mismatchfee_type isn't the fee's type.
user_request_booking_mismatchThe request is for a different booking.
user_request_passenger_mismatchThe request is for a different passenger.
user_request_leg_mismatchThe fee is for the other leg.
payment_unreachablePayment service didn't answer; the charge may have gone through.

Errors from the fee itself:

ErrorMeaning
MISSING_DEPARTURE_ARRIVAL_ETICKET_IDNeither e-ticket id was sent.
not_foundUnknown booking_history_id.
INVALID_ETICKET_IDNo passenger on the booking has that e-ticket.
missing_fee_dataThe input matching fee_type — baggage, seat or other_fee — is missing.
invalid_transaction_timetransaction_time is in the future.
invalid_dataThe baggage is no bigger than what the passenger already has on that leg.
already_has_seatThe passenger already has a seat on that leg.

It can also return Middleware Errors.