---
# System prepended metadata

title: POLL Schema V2

---

# 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