pay_with_corporate

Step 8 for a corporate booking — charges the confirmed session against the corporate balance. It needs a session that still exists, was confirmed at step 7, and had the corporate flag turned on at step 5 of the payment flow.

It is a GraphQL mutation returning Boolean.

Arguments

Argument	Description
payment_checkout_session_id	String! — required. The checkout session to charge: the one opened at step 4 and confirmed at step 7.
otp	NonBlankString — optional. One-time password for the call.

NonBlankString is a custom scalar, so otp is either absent or a non-blank value — passing an empty string is rejected by the scalar rather than by the mutation.

Each argument pairs with one of the errors below: a payment_checkout_session_id that no longer resolves gives not_found, and omitting otp when the call demands one gives otp_required — supplying the argument is how a client satisfies that on the retry.

Response

Returns Boolean — nullable, not Boolean!.

Outcome	Response
Success	true
Failure	The field resolves to null and the error is carried in the response's error path — see Errors

Because the return type is a scalar, the mutation takes no selection set:

Mutation

mutation PayWithCorporate($session_id: String!, $otp: NonBlankString) {
  pay_with_corporate(
    payment_checkout_session_id: $session_id
    otp: $otp
  )
}

Note what this means for a client: failure arrives as an error, not as false. Checking the boolean alone is not enough — a caller has to inspect the error path, because a payment that didn't go through never comes back as a plain false result.

Errors

Error	Meaning
not_found	The payment checkout session has been deleted.
not_corporate_payment	The payment is not a corporate payment.
not_enough	The corporate owner's corporate balance is less than the price.
SOLD_OUT	The item is sold out.

not_corporate_payment is what you get when the session was never switched to corporate — enable defaults to false, so reaching this call without a step 5 that set it to true fails here rather than at step 5.

Note the casing: SOLD_OUT is upper-case while the other three are lower-case, which suggests it surfaces from a different layer than the store service's own validation.

Errors from the shared sets

On top of its own four codes, pay_with_corporate can return either shared set:

• Middleware Errors — unauthenticated, unauthorized, unauthorized_delegation, otp_required, raised before the call reaches the store service.
• Trip-Related Errors — budget, guest, and traveller validation failures when the booking is a trip.

So a client calling pay_with_corporate has to handle all three sets, not just the table above.

Still to document

• The GraphQL endpoint it is served from.
• Authentication — presumably the standard Authorization user token, unconfirmed.
• How the error codes are carried in the GraphQL response — as the message of an entry in errors[], or under extensions.code.
• Whether false is ever returned, or whether every failure is an error.
• Why SOLD_OUT is upper-case while the other three are lower-case — whether it's forwarded from another service, and whether clients should match case-insensitively.