# POLL Schema V2
Poll
bookings: list[Booking]
#
error: Error
threeDS: ThreeDS
partial_success: ? - we need to indicate at some point to the customer that he shouldn't just close the page and provide him enough instructions
mismatch: FareMismatch

Booking
booking_type: service/flight
flight: Flight | None
...
iata
bundle_code (fare code)
bundle?
price: Price
status: BookingStatus - from client perspective can be success(V) /failure(X) / not_started(.) / in_progress(~)

Flight:
legs: list[Leg]
PNR: str | None

# POLL Schema V1

Orders
list[Order / Transaction]
# always render "progress screen"
# buble up 3ds iframe
# buble up Retry on failure screen with propper inputs (card/etc)

Order
id: (flight_booking_id)
status: in_progress, 3ds, pending, failed, cancelled, success
vendor_order_reference: (pnr)
? IMO we could not care about not_started, we could not care about second refresh
?
error: Error
3ds: 3ds

Transaction:
id: (service_booking_id / shared_auth_id)
status: in_progress, 3ds, failed, cancelled, succes
type: authentication / payment
3ds: 3ds

Error:
type
? recoverable
? specify what to re-post

How does client understand what to do?
Currently we have both mb_status and individual statuses which we have to respect
E.g you could from some states:
partiall_success(failed ): non recoverable failure
partiall_success(in progress): 3ds in second booking
partiall_success(pending ): some booking is yet pending
failure (recoverable): payment error in service fee payment
failure (unrecoverbl): system error at service fee payment of some kind
in_progress (in progress): ...

IMO we should have simplier framework:
you always render the "progress screen"
you always render action screens - Retry, 3DS

? how not to render partiall success all the time ?

ITEMS_TO_RENDER[
3DS_,
IN_PROGRESS_SCREEN {3 objects, {reference, status, vendor}, {reference, status, vendor}}
]

ITEMS_TO_RENDER[
IN_PROGRESS_SCREEN
]

ITEMS_TO_RENDER[
ERROR_INPUT(card),
PSB_SCREEN,
]

ITEMS_TO_RENDER[
ERROR_UNRECOVARABLE,
]

### KRIS

  {
    transactions: [
      {
        bkid,
        status,
        price,
      },
      ...
    ],
    3ds: {
      bkids: [],
      data_to_render,
      ...
    }
    error {
        // information about booking/shared_auth/whatever goes here also
        recoverable: true,
        type: 'payment_error'
        subtype: 'cvc_invalid',
        payment_data: {
          pci_token,
          expiration,
          card_holder_name
        }
    }
  }
  
  
Error ideas

errors: [
  {
    type: 'payment_error.cvc_error',
    payment_data: {
      pci_token,
      expiration,
      card_holder_name
    }
  },
  {
    type: 'pax_data_error.invalid_date_of_birth',
    pax_data: {
      pax_id,
      first_name,
      last_name,
      date_of_birth,
      card_holder_name
    }
  },
]

{
  bookings: {
    status: 'IN_PROGRESS' | 'FAILED' | 'SUCCESS',
    price
  },
  3DS: {
    action,
    ...
  },
  error: {
    type: 'payment_error',
    is_recoverable: true,
    payment_fields: {
      pci_token,
      expiration,
      card_holder_name
    },
    errors: [
    {
      field: 'card_holder_name'
      code_for_cms: 'too_long'
    },
    {
      field: 'expiration'
      code_for_cms: 'invalid_date'
    }
  }
}

Links:
https://laravel.com/docs/9.x/validation#validation-error-response-format
https://stackoverflow.com/questions/39759906/validation-error-responses-in-rest-api