►
From YouTube: OpenActive W3C Community Group Meeting / 2018-10-10
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda and summary: https://w3c.openactive.io/meetings/2018-10-10-booking-api-update-and-feedback
For more information visit: https://www.openactive.io/w3c-community/
C
D
A
A
And
then
we
wanted
to
focus
most
of
the
call
on
having
a
discussion
around
some
of
that
feedback,
focusing
on
the
way
that
the
API
flow
currently
works
or
could
could
work
in
future
based
on
some
preferences
of
people
are
shared,
so
I
woke
up
amazed
at
the
end,
if
anyone's
got
any
other
issues
to
raise
so
in
terms
of
a
progress
update.
Hopefully
you
all
saw
that
we
published
the
the
2.0
data
model
specification
last
week,
and
so
thanks
to
everybody
that
contributed
to
that
piece
of
work
and
the
descriptions
I'm
getting
it
updated.
A
A
A
E
A
E
A
C
A
Thanks
and
you've
jumped
ahead
a
little
bit
further
if
I
was
going
to
mention,
but
yes
and
in
terms
of
improving
documentation
for
the
API
is,
then
that
is
something
that
we
will
be
looking
at
and
so
what's
in
the
current
developer
site
at
the
moment,
this
is
some
basic
background.
Information
on
what
a
day
to
feed
is
how
they
work
reference
to
the
day's
models.
There's
a
little
explainer
video
for
the
real-time
page
data
API.
A
Keep
this
best
for
formal
specifications
as
the
kind
of
authoritative
source
will
be
this
reference,
if
additional
reference,
implementation,
tutorials
and
then
we'll
add
to
it
over
time
with
some
and
swagger
documentation,
which
you
previously
highlighted,
and
we
did
have
for
some
of
the
earlier
iterations
of
the
booking
spec,
and
so
we
have
take
a
look
at
the
developer
site
happy
to
take
feedback
on
the
content.
That's
in
there
in
terms
of
where
we're
at
with
the
booking
work,
we've
been
interested.
A
A
We
want
to
leave
some
time
for
iteration
based
on
discussions
like
we're
gonna
have
in
the
moment,
but
also
to
give
time
for
implementations,
because
what
we're
finding
is
that
we
get
some
attention
on
spec
and
some
useful
feedback.
But
when
people
actually
start
to
try
and
implementing
it,
it
throws
up
a
bunch
of
questions
and
more
detailed
bits
of
feedback
and
which
tends
to
come
through
in
sort
of
drips
and
drabs
so,
but
only
explicitly
to
a
number
of
people
about
I'm
trying
to
get
implementations
up
and
running.
A
And
so
we
want
to
kind
of
give
a
bit
of
time
to
collect
that
feedback
from
practical
use
before
rubber-stamping
in
the
spec,
so
that
everyone's
got
confidence
that
what
we
got
in
one
point.
O
is
a
implementable
specification
that
will
give
us
a
useful
foundation
for
or
some
of
the
other
requirements
that
we
talked
about
in
some
of
our
workshops
and
discussions
over
the
last
few
months.
A
For
some
of
that-
and
we
haven't
quite
bottom
doubt
that
the
technoboy
technical
solution
there
yet
and
some
of
the
new
stuff
that's
come
up
in
the
last
few
weeks
and
some
feedback
on
how
pricing
is
handled
and
described
in
the
API
response,
and
particularly
that
we're
not
we're
not
talking
about
tax,
we're
not
highlighting
where
there's
the
80
or
the
tax
to
be
paid
on
that.
So
it
makes
a
part
of
the
pricing
and
clarifying
how
that
gets
handled
through
the
workflow
as
people
starting
to
implementing
it.
A
We're
also
getting
questions
around
the
scope
of
the
spec.
What
we
want
to
try
and
achieve
with
1.0
and
then
how
we
might
build
on
that
core
to
add
in
or
the
other
requirements.
You
know
whether
it's
arounds
waiting
lists
or
customers
etc.
So,
there's
there's
some
work
kind
of
communications
and
outreach
work
that
we
need
to
be
doing
there
and
but
the
probably
the
most
consistent
bit
of
feedback
we've
had
so
far
is
I'm.
A
Some
concerns
over
the
API
workflow
and
so
the
number
of
calls
that
are
required
in
order
to
complete
an
order,
and
particularly
if
it's
free.
So
the
user
doesn't
have
to
provide
any
payment
and
questions
around
how
much
state
needs
to
be
maintained
by
the
booking
platform
as
part
of
servicing
a
series
of
requests
from
clients.
A
So
because
that's
probably
the
most
significant
one.
You
know
if
we
need
to
change
the
the
workflow
that
that
could
have
a
larger
impact
on
the
spec.
We
wanted
to
have
a
discussion
about
that
this
afternoon,
and
so
before
we
jump
into
that
any
other
comments
or
questions
about
where
we're
at
with
booking
I.
F
If
that
makes
sense,
as
opposed
to,
maybe
you
want
to
poll
30
different
slots
at
the
same
time
is
quite
an
expensive
process
to
get
that
information
back
and
I
didn't
know
if
batch
requests
is
something
that
could
fit
within
looking
spec
or
something
to
think
about
in
the
future,
because
otherwise
you
have
to
it's
not
so
much
of
a
concern
of
the
person
of
the
service
making
a
request
but
more
for
the
service
having
to
deliver
more.
So
that
could
be
potentially
a
lot
of
work,
a
lot
of
course,
but
otherwise,
now
yeah.
A
Okay,
so
there
is
a
reason
issue
on
the
the
backlog
that
relates
to
that,
and
you
know
how
well
the
current
approach
to
availability
checking
scales
with
situations
where
there's
a
large
number
of
slots,
for
example.
So
there
is
a
discussion
that
we
can
continue
into
you
there,
but
I
think
some
of
that
also
relates
to
just
adjust
the
number
of
calls
in
general,
so
I'm.
What
I'm
going
to
do
is
exactly
Hanno's
Nick
to
lead
us
to
the
next
bit
of
the
decision,
because
so
Nick
you
on
there
yeah.
D
D
So
that's
kind
of
what
sparked
this
conversation
in
the
first
place,
but
then
a
few
other
people
have
chipped
in
and
so
at
the
moment
most
third-party
booking
flows
tend
to
capture
what
you
can
see
here,
which
is
an
email
address
for
name,
surname
credit
card
number
and
have
a
go
button,
and
that's
what
that's
the
kind
of
minimum
amount
of
information
to
capture,
sometimes
there's
a
registration
process
as
well.
You
go
through
that.
D
Maybe
it
you
know,
creates
something
in
their
account
whatever
whatever
some
of
that
stuff
is
done,
like
an
email
is
a
one
one-off
thing:
you
don't
really
want
be
sending
a
cancellation,
translation
team
or
immediately
afterwards,
so
the
booking
happens
at
the
end,
and
we
want
to
confirm
that
is
done
in
some
booking
systems.
You
actually
can't
undo
that
within
the
API,
although
that's
something
that
obviously
will
be
good
in
the
future.
D
So
that's
the
idea
of
that
kind
of
flow,
and
so,
if
there's
an
issue
with
the
lease-
and
you
can't
reserve
the
slot,
of
course
nothing
happens-
you
stop
there.
So
the
two
things
would
be
interested
to
talk
about
today
are
around
around
that.
So
does
everyone
understand
what
I've
just
kind
of
talked
about
in
the
context
of
that
before
we
talk
about
the
discussion
points.
D
Okay,
yep
great
and
I'm,
looking
at
some
nodding,
if
you're,
not
if
you're,
not
visible,
then
shout
so.
The
two
kind
of
key
questions
here
are:
there's
an
anonymous
lease
question,
which
is
just
clarifying
what
we
currently
got
in
the
spec
and
making
sure
that's
what
everyone
wants
and
if
that
fits
the
interfaces
from
both
the
consumer
and
brokers
perspective
and
also
the
booking
system
perspective
and
the
customers
of
the
booking
system,
and
then
there's
this
question
about
this.
The
lease
book,
two
things
that
we
could
do
at
the
moment,
the
two
different
calls.
D
That
is
two
calls,
there's
a
main
point
people
have
made
before,
which
is
there
a
reason.
While
we're
doing
this,
we
have
to
store
state
in
between
the
two
calls
to
do
that
successfully
to
make
the
lease
actually
work,
which
adds
overhead
to
all
the
different
booking
systems.
So
there's
a
question
about
that,
but
before
we
get
into
that,
we
probably
need
to
clarify
the
first
point
here,
which
is
non
immerses.
D
So,
just
on
the
next
slide,
then
one
of
the
things
that
we
had
as
an
initial
requirement
in
the
requirements
covering
workshop
was
to
reserve
a
place
for
a
user
while
they're
doing
their
stuff,
while
they're
entering
their
details.
Now
that's
kind
of
fallen
out
of
the
requirements
out
of
the
at
the
spec,
not
potenti,
entirely
purposefully,
and
that's
one
of
the
reasons
we're
surfacing
it
here,
because
it's
so
everyone
has
a
site
of,
and
and
so
the
question
is
about
this
requirement,
and
in
is
it
something
that
we
can
support
both?
D
Is
it
something
that
we
want
from
the
users
perspective?
Is
it
something
that
we
want
to
support
from
a
booking
system
perspective
and
so
for
a
third
party
booking
system?
Where
you
don't
know
who
the
user
is
and
here's
two
examples:
you've
got
a
stripe
standard
flow
where
you
can
see,
but
email
address
and
card
details
in
all
at
once,
and
you
press
pay,
that's
quite
used
quite
a
lot
on
smaller
websites
online
and
you've
got
Ticketmaster
as
an
alternative.
D
So,
on
the
first
the
left
hand,
side,
you've
got
kind
of
you
can
just
look
it.
That's
what
Amazon
does
that's
what
other
websites
and
Ticketmaster
you
actually
reserve
the
spot
while
you're
typing
the
details,
so
you
can
see
the
top
right
there,
there's
a
timer.
Now,
that's
actually
five
minutes
started
entirely
anonymously.
So
I
was
just
trying
to
book
a
ticket
for
Hamilton
at
least
a
day
and
that
that
time
has
started.
D
I
didn't
put
any
details
in
well,
that's
Sweden
sure
that
seat
3132
only
for
me
and
they
can't
be
booked
for
anybody
else,
while
I'm
going
through
the
process
of
filling
that
in
and
so
there's
a
question
here,
because
amazon.com
does
the
first
of
those
so
Amazon
you
actually
don't.
If
you
put
some
in
a
basket,
it's
only
when
you
press
checkout
and
pay
that
you
actually
have
that
item.
So
someone
else
can
beat
you
to
it
and
that's
the
case
across
most
ecommerce
sites,
because
obviously
they're
optimizing
for
purchase.
D
So
they
really
care
when
people
are
thinking
about
buying
it
they're
carrying
about
the
person
that
wants
to
buy
it,
and
they
want
to
know
that
a
person
through
first,
because
otherwise
you
might
lose
that
person
and
the
person
who's.
Taking
the
time
to
think
about
it
might
never
book,
and
so
obviously
that's
optimizing
for
just
the
revenue
of
the
provider.
There.
However,
there's
a
user
experience
angle
to
this,
which
is
where
the
theatres
booking
systems
take
as
their
approach,
which
is
maybe
I'm
going
to
be
disappointed
as
a
person.
D
This
is
a
question
really
on
both
sides?
Is
this
something
that,
as
a
booking
system,
is
you
support
that
you're
interested
in
supporting
to
allow
people
to
start
to
create
that
kind
of
user
experience
and
from
a
data
consumer
perspective?
Is
that
something
that
you
want
to
do?
Is
it
something
you're
currently
doing.
F
So,
from
from
a
perspective,
the
Amazon
issue
is
I,
guess,
most
of
the
time,
an
edge
case
because
you're
bidding
for
one
item
of
which
there
are
multiple
duplicates
right,
and
so
there
are
more
often
more
items
and
there
are
people
booking
at
any
one
time.
But
when
you're
booking,
for
example,
a
theater,
the
odds
are
that
they're
going
to
be
10
people
at
the
same
time
aiming
for
that
slot.
So
it's
a
much
worse
user
experience
for
the
10
for
one
slot,
and
so
it's
an
abundance
question
for
me.
F
I
think
more
often
than
not,
there's
probably
going
to
be
more
slots
available
than
there
are
people
and
you're
going
to
be
going
for
a
generic
like
a
generic
slot
within
a
session
rather
than
I'm
having
the
third
Matt,
and
so
perhaps
in
that
kind
of
environment.
Where
there's
no
geolocation
people
are
gonna,
be
bidding
for
preferred
slots,
then
it
works
with
the
second.
You
introduce
something
like
which
court
are
you
going
to
be
booking,
then?
For
me,
the
second
one
makes
sense.
F
D
C
Me
have
a
go,
as
you
might
have
guessed:
Nikki
I'm
quite
prepared
to
make
a
statement
right.
Okay,
so
I
think
it
depends
a
lot
on
the
use
cases
as
well.
So
if
we
look
at
the
way
our
our
providers
work,
there's
a
whole
bunch
of
classes
or
courts
that
get
fully
booked
within
seconds
as
soon
as
they're
available
yeah.
So
if
what
we're
expecting
is
to
model
or
support
their
current
customer
base,
then
we
do
need
that
leasing
because
by
the
time
gets
with
the
basket.
C
If
it's
more
about
excess
capacity,
so
you're
saying
well,
you
know
we
got
20%
of
our
30%
40%
50%
of
our
classes
are
really
popular
and
the
rest
no
one
goes
to.
Then
we
about
the
Amazon
thing,
where
you're
unlikely
to
get
bothered
in
the
meantime,
so
I
think
there's
an
extent
which
is
about
what
the
providers
want
to.
C
Let
go
of
and
I
think
most
of
our
providers
will
not
be
very
happy
about
their
really
really
popular
classes,
getting
out
through
a
third
party
site
so
with
us
about
timing
of
the
availability,
that's
a
whole
different
story.
I
think.
The
other
thing
from
our
perspective
is
that
it's
very
difficult,
if
not
impossible,
for
us
to
do
an
anonymous
lease
from
a
technical
perspective.
So
when
we
lease
its
saying
mr.
C
John
Smith
would
like
to
book
this
class
and
we'll
let
you
know
if
it
gets
around
to
paying
for
it,
we
don't
really
have
the
concept
of
anonymously
from
a
technical
perspective
and
that
idea
of
a
an
account
till
the
booking
is
kind
of
very
heavily
baked
in
and
I'm,
not
quite
sure
we
could
take
a
nominal
anonymous
member
if
you
like,
and
then
swap
them
out.
I'd
need
to
check
on
that
with
some
more
technical
people
than
me.
F
Other
concern
you
might
have
with
anonymous
leasing
is
a
single
user,
could
open
up
the
at
least
the
the
booking
page
in
twenty
windows
and
at
least
20
of
those
booking
slots
anonymously,
and
then
all
of
a
sudden.
Nobody
can
book,
because
there
is
no
availability.
Even
though
only
one
of
those
windows
is
going
to
be
used,
which
is
then
becomes
a
challenge.
But
someone
like
Ticketmaster
can
deal
with
that
problem
because
they
own
the
user
interface,
and
so
they
can
actually
work
out.
F
C
Sorry
me
again,
I'm
just
going
back
to
use
cases
what
this
is
a
question.
That's
this
piece
of
string
one
and
what's
the
balance,
do
we
think
between
people
and
a
third
party
site
you've
never
been
there
before,
and
people
will
repeat
offenders,
because
in
most
people
repeat
offenders,
there's
probably
some
login
process
or
the
could
be
login
process.
F
The
the
flow
we
usually
get
on
our
site
is:
we
have
return
users
that
go
straight
to
our
service
and
we
don't
want
to
create
a
login
barrier,
so
they
will
return
to
our
site.
They'll.
Do
that
search,
they'll,
select
that
class
they'll
click
to
book,
and
at
that
point
they
login
and
by
which
point
they
would
at
least
already
so.
The
majority
of
the
leases
will
be
by
non
misuses
from
our
perspective
until
we
get
them
to
enter
the
details
and
login.
F
So
the
question
there
is
around
how
to
manage
anonymous
leasing
for
known
users
that
aren't
aren't
there
so
Amazon,
for
example,
there's
optimistic
login.
So
it
assumes
that
if
you've
been
on
that
device
before-
and
you
still
have
an
odd
cookie-
then
you're
kind
of
logged
in-
but
you
can't
book
anything
you
come,
you
can't
pay
for
anything
and
then
that's
when
they
introduced
the
no.
You
could
actually
look
back
in,
but
we'll
assume
you're,
the
previous
user,
and
so
that
can
be
a
model
that
you
can
take.
G
H
That
rings
true,
with
with
the
case
of
booking
bug
to
quite
a
large
extent.
Yeah
we've
got
a
nation
of
held
items
so
we're
able
to
hold
the
appointment
until
the
customers
completed
some
details
and
then
they
complete
the
booking
process.
Then
we
actually
have
the
payment
as
a
separate
process
that
happens
after
that,
and
we
would
cancel
the
booking
if
it
hasn't
been
paid
for
at
that
point.
H
So
yeah
I
can
see
how
what
we
do
maps
to
what
you
guys
have
been
coming
up
with
I
mean
in
terms
of
them
being
anonymous.
It's
it's
something
that
we've!
You
know
it's,
it's
very
rare
for
us
to
not
even
have
an
email
address
it.
It
has
come
up,
but-
and
so
we've
had
to
support
it
in
the
past,
but
it's
relatively
unheard
of
for
us
to
have
to
have
to
deal
with
an
anonymous
situations.
D
So
it's
not
ly
what's
emerging
here
and
James.
Just
think
me
to
say:
he's
had
tech
issues,
so
he's
gonna
come
and
rejoin
again,
and
so
one
of
them.
It
sounds
like
there's
a
half
way
here
where
people
enter
their
registration
details
and
then
enter
the
payment
details
and
that
the
first
part
of
that
process
is
is.
D
Obviously
it's
the
same
thing
because
you
can
you
logged
in
and
actually
you
don't
need
to
have
a
lease
you
can
just
pay
with
one-click
booking
Amazon
style
and
so
I
suppose
I'm
trying
to
figure
out
what
the
value
is
of
that
it
sounds
like
there's
a
there's
a
half
way
here
and
what
the
value
of
that
is.
Is
that
something
really
useful
to
provide
to
people
so
that
if
they're
in
they
can
enter
their
credit
card
details
in
their
their
safe
during
that
period,
but
the
bit
before
that
was
where
they
were
unsafe?
D
Or
is
it
that
we
want
to
say
if
you're
logged
in
and
you're
giving
any
credit
card
details,
then
you
can
book
stuff
quickly
if
you're
the
kind
of
person
that
wants
to
be
booking
a
balance
in
court
when
there's
only
one
left
and
you're
booking
at
midnight,
because
that's
when
those
things
happen
generally
during
the
day,
this
stuff
doesn't
really
affect
it
right.
But
there
are
crucial
times
when,
as
ian
was
saying,
there
are
stuff
that
gets
booked
up
and
everyone
goes
crazy
for
it.
D
F
Concern
would
be
without
the
lease,
because
the
lease
holds
a
stop,
then
the
payment
happens
and
then
the
booking
occurs
right.
If,
as
and
as
a
broker,
we
take
the
payment
and
then
try
and
book
the
slot,
and
it's
not
there.
Then
we
have
to
handle
that
process
like
then
giving
a
refund
to
the
user,
which
isn't
necessarily
always
the
smoothest
way
of
doing
it.
So.
D
B
A
Happen
just
before
we
fully
move
on
and
I
was
just
mulling
over
and
other
reasons
for
having
that
lease.
So
one
of
the
arguments
for
having
lease
is
to
give
people
time
to
enter
payment
details.
One
of
the
one
of
the
that
we've
got
on
the
backlog.
To
think
about
is
people
providing
a
dish
answering
a
whole
set
of
additional
questions
as
part
of
making
a
booking
so
information
that
needs
to
go
to
the
organizer
or
etc,
or
just
the
things
that
have
to
be
collected.
B
A
Argument
for
giving
people
a
bit
of
a
window
to
enter
things.
It
may
be
that
those
could
be
done
after
the
actual
booking
is
placed,
but
it
have
to
think
about
how
that
well.
I
think
what
I'm
saying
is.
We
have
to
think
about
some
of
this
other
stuff
as
well
and
where
this
fits
in
the
workflow
at
what
point
that
will
be
passed
to
the
booking
system.
H
Yeah,
that's
definitely
what
we've
got
in
our
case.
It's
that
yeah
we
have
these
held
held
items
for
when
we
need
to
have
long
forms
of
customer
information
that
they
need
to
be
put
in.
It's
just
that
we
do,
but
it's
just
that
separate
from
the
actual
booking
process
before
payment.
Is
there
yeah?
That
held
item
is
the
temporary
thing.
That's
not
booked
yet,
but
it
is
for
that
very
purpose
of
they
might
want
to
enter
in
a
lot
of
information
after
they've
selected
their
time,
and
they
don't
want
to
lose
that
time.
A
F
Okay,
so
the
same
thing
so
with
our
users
they
might
own
in,
might
they
might
be
making
one
booking
through
one
provider
and
another
booking
through
the
other,
with
a
basket
as
it
were,
and
then
perhaps
checking
out
once
with
a
single
payment,
because
we
might
be
aggregating
certain
things,
and
so
it
could
be
for
our
users.
A
slightly
strange
experience
to
have
part
of
it
suddenly
confirmed,
but
not
the
rest
of
their
the
rest
of
their
booking
is
aware.
F
C
So
that's
what
I
think
Nick
was
saying
by
the
halfway
house
so
carry
on
with
that
from
what
Tooley
was
saying.
If
you
do
do
that,
there's
no
reason
why
you
can't
add
extra
information
afterwards
after
you
would
register
logged
in
Nick
I
want
to
ask
if
that's
what
you're
trying
to
say
if
I
got
that
correct
yeah,
that's
right
because
I
think
that's
quite
a
good
compromise.
C
D
Obviously
it
comes
at
the
cost
of
a
slightly
more
complex
process,
which
is
something
that
we
want
at
the
moment
is
it's
kind
of
a
mandatory
element
in
the
spec,
and
this
is
one
of
Gleaners
comments
originally
around
the
complexity,
so
just
to
quickly
touch
on
some
other
bits
of
content
and
then
to
just
then
conclude
the
discussion
with
with
revisiting
the
whole
the
whole
thing
together.
I
suppose
we've
got
both
bits
of
this
covered,
so
just
on
this
bit,
then
there's
a
there's
two
options.
D
This
is
exactly
what
Kent
was
just
kind
of
talking
about,
so
there's
a
two
step,
booking
approach
which
you
can
take,
which
is
where
you
lease
as
we're
saying,
which
you
would
need
either
anonymously
to
do,
or
you
would
need
some
personal
details
and
we're
saying
you
can
have
to
make
a
book
at
least
at
the
halfway
house.
That
gives
you
the
assurance
you
need
to
capture
the
payment
and
then,
when
you
cut
the
payment
you
can
make
the
booking
the
alternative
is,
and
it's
something
that
what
I've
seen
and
it's
interesting.
D
What
can
you
were
saying
about
some?
Not
all
providers
supporting
us,
because
we
found
the
research
we
did.
Most
of
them
seem
to
be
supporting
and
actually
saying
it
was.
It
was
let's
practice,
dohno
might
be.
So
we
can
pick
up
on
that.
But-
and
there
is
another
approach
which
is
supported
by
certainly
some
of
the
larger
payment
providers,
which
is
that
you
authorize
the
payment
first
and
which
effectively
leases
the
payment
side
rather
than
leasing
the
booking.
You
then
make
the
booking
in
the
booking
system
as
just
a
single
post.
D
D
So
some
reason,
if
you
don't
get
to
stay
at
step
three,
then
either
the
authorization
after
a
certain
number
of
days
or
or
minutes
depending
on
what
you
set
up
is
automatically
just
disappears
because
that's
how
the
payments
process
works,
and
so,
if
you
don't,
if
you
don't
ever
reverse
it
or
you
can
you
can
tell
them
provider
to
just
undo
the
authorization
and
in
those
cases
the
the
user
won't
get
in
our
credit
card,
stealing
their
bank
balance.
They
won't
see
anything
about
the
transaction
ever
occurred
there.
D
One
of
the
things
I
was
interested
in
is
is
as
a
discussion
point,
because
it's
almost
really
the
rest
of
its
detail
in
terms
of
how
it
work
I
mean
it
might
just
be
to
just
kind
of
flesh.
This
out
to
go
to
the
next
slide,
what
that
could
look
like
as
opposed
to
what
we
currently
have.
Is
you
you
basically
and-
and
this
is
the
way
that
Google
Reserve
does
it
as
well,
which
is
another
interesting
example,
and
you
do
what
I've
called
here
a
quote.
D
Basically,
it's
like
a
you
basically
say:
I've
got
these
five
items
in
my
basket.
Can
I
book
them
and
the
answer
might
be
yes
or
it
might
be?
No
because
actually
both
over
on
the
same
physical
court
and
you
can't
book
them
together
or
because
one
of
them
disappeared.
Since
you
last
checked
so
you
have
this
call
that
you
can
make,
and
every
time
you
add
something
to
your
basket,
the
user
experience
it.
You
add,
you
made
that
call
to
just
double
check
that
that
basket
still
rat
valid.
D
If
something
disappears
at
some
point,
when
you're
in
the
flow,
then
you
can
notify
the
user
and
say
that
thing
it
was
baskets
gone
now.
Sorry,
you
were
too
slow
and
and
then
that
does
the
check
and
then
basically
you
do
the
other
we'll
just
discuss
that
you
authorize
the
payment
amount.
You
then
completely
order,
and
then
you
capture
the
payment,
and
so
that
and
in
terms
of
API
calls-
and
this
is
I-
was
interested
spring
in
common
Galina,
and
this
is
obviously
the
minimum
here.
Is
you
don't
even
need
to
check?
D
D
If
you
have
that
knowledge,
then
actually
you
just
need
one
call,
which
is
just
a
book
you
can
just
with
one
call
make
the
booking
and
so
and
if
for
free,
it
causes
what
for
a
free
event
as
well,
if
you're
sure
that
it's
free
you're
not
taking
any
payment
details,
you
can
just
make
the
same
one
call
and
it
will
confirm
or
not
that
that's
been
completed,
but
you
really
would.
Obviously,
if
you
were
going
to
a
registration
process,
you
would
make
the
first
call
web
first
to
check.
I
D
J
Yeah,
so
there's
not
much
to
add
here.
I
just
wanted
to
say
that
really,
if
you
have
a
lot
of
customers
who
is
like
many
classes
and
that
we
have
to
cool
at
once,
and
for
example,
when
some
member
is
trying
to
book
a
class,
it's
it's
really
crucial
that
that
goal
is
is
quick,
so
we
don't
have
to
like
show
handless
spinners
inside
the
app
while
are
doing
a
multiple
calls
to
to
system
like
class
booking
system.
So
that
is
why,
as
less
ghosts
as
possible
would
be
great
just
a
second.
C
Think
that
I
kind
of
split
down
things
that
free
and
things
aren't
free,
certainly
I,
don't
see
the
reason
why
the
post-order
couldn't
you
know
the
quote.
So
if
you
know
everything
about
the
order
and
it's
been
authorized,
then
you
can
put
it
in,
but
there
must
be
the
ability
to
back
out
at
that
point.
So
one
of
the
things
I
think
that
we
need
to
identify
with
this
person
by
the
way.
This
is
broadly
the
process
that
we
follow
anyway,
is:
what's
how
do
we
handle
the
error
conditions?
C
So
if
we
don't
get
a
response
about
from
number
three
as
an
aggregator,
and
what
do
we
do?
Do
you
assume
it's
not
gone
through?
Do
we
have
someone
ask
loop
it's
gone
through.
Obviously
there
will
be
some
error
state.
If
you're
not
leasing
items
in
option
one
then
they
may
well
have
gone
away,
in
which
case
some
may
have
gone
away
in
some
not,
and
so
how
are
you
going
to
present
that
to
the
customer
when
they've
paid
their
$30-
and
it
comes
back,
says
oh
will
give
me
half
it
back?
D
So
you
can't,
you
can
confirm
anything
up
to
the
authorized
amount,
but
then
that
was
a
good
question.
Actually
my
my
next
slide.
If
we
got
there,
which
was
exactly
that
question
does,
but
does
a
user
actually
want
to
have
half
their
stuff
confirmed
because
if,
if
actually
the
kids
haven't
got
into
their
their
crash
or
whatever
it
is
and
I
may
be
still
I
don't
want
to
go
anymore
because
they
can't
go
or
you
know
it
might
be
a
reason
why
you
try
to
book
all
those
things
together
and.
C
K
K
K
When
we
send
payment
and
detail
of
our
API
using
stripe,
we
actually
collect
the
user
details
off
strike
and
then
stripe
has
just
used
to
process
the
payment.
So
you'll
still
have
the
name
and
any
other
information.
You'll
want
from
the
user,
like
phone
number
and
email
address
and
you'll
send
and
we
send
that
to
the
banking
system.
And
then
we
send
the
we
get
the
payment
from
stripe
and
sender
taken
from
there.
But
it's
using
a
combination
of
our
own
system
and
what
we
collect
from
stripe.
D
So
that,
basically
saying
when
you,
when
you
capture
thee,
it's
actually
slightly
different
to
this,
because
you're
saying
you
capture
the
the
card
details
first
from
stripe,
that
comes
with
the
kind
of
email
address,
and
then
you
use
that
to
make.
If
you
want,
you
could
use
that
to
make
a
lease,
but
we're
still,
if
you
go
back
a
step
Li
to
the
previous
slide,
so
I
guess
still
both
of
these
would
be
possible
with
that
approach,
because
yeah.
K
D
Either
at
the
point
where
you
talk
to
strive,
you
could
then
use
that
same
content,
you've
captured
to
off
the
pain
and
then
go
through
and
do
two
and
three
on
the
right-hand
side.
Yeah
or
you
could,
as
you
say,
you're
taking
that
same
detail
from
striping.
Instead
of
that
you're,
putting
into
leasing
an
order
into
one
and
then
going
through
and
capturing
the
payment
and
booking.
K
D
F
F
I.
Think.
The
point
for
me
is
this
shift
to
the
new
four
point
structure:
you're
talking
about
two
steps.
That
makes
a
lot
of
sense.
It
does
move
it
to
stateless,
which
I
think
actually
probably
presents
a
more
stable
way
of
dealing
with
it
because
I
don't
know
the
names
of
person
who
raised
it
there.
The
issue
of
errors
is
always
going
to
turn
up
right.
That's
almost
a
guaranteed
thing
with
web
transactions.
So
if
you're
dealing
with
errors,
then
you
kind
of
want
to
you.
F
Kinda
want
a
system,
that's
resilient
to
it
and
that's
very
much.
The
same
problem
is
when
you're
trying
to
process
part
of
the
transaction
or
what
no
there's
a
single
transaction
and
then
the
resource
becoming
unavailable.
So
maybe
stateless
as
a
model
is
actually
more
resilient.
It
might
not
be
the
best
user
experience,
but
it's
certainly
more
technically
resilient.
So
good.
A
A
D
D
But
I
see
that
I
guess
so.
Yeah,
there's
probably
there's
a
stateless
paradigm
thing
around
this
approach,
which
is
like
you
say,
I
guess,
that's
probably
why
that's
happened,
but
it
sounds
like
because
so
here's
a
suggestion,
I,
don't
know
what
people
think,
because
if
let's
say
that
we
had
a
setup
like
this,
where
it
was
stateless.
However,
you
could
optionally
create
a
lease
at
an
earlier
point
in
the
process.
D
If
so,
at
the
moment,
the
situation
we're
in
is
we've
got
it's
a
mandatory
leasing
situation,
so
everyone's
got
to
implement
leases
in
systems
both
sides
and
so
I.
Suppose
the
question
is:
if,
if
we
all,
if
that's
a
common
case-
and
everyone
thinks
we
want
them,
then
obviously
that
that
is
that
complexity,
that's
useful,
if
it's
the
case
so
actually
there's
some
systems
will
want
it.
Some
systems
won't
actually
is
green.
B
K
Think,
from
our
point
of
view,
we
have
been
operating
on
the
basis
of
just
making
the
working
immediately
without
the
need
of
a
release,
I
believe-
and
it's
not
ideal,
but
it
does
work
our
error
rates
around
2%
for
facilities.
So
it's
something
that
we
would
like
to
cut
out.
But
if
there
is
come
staggered
approach,
then
that
might
be
more
sensible
at
this
point.
C
K
D
K
D
A
So
we've
got
a
only
a
few
minutes
left
on
the
call
and
while
I
don't
this
is
really
good
discussion.
I
don't
really
want
to
stop
it,
but
they've
got
limited
time
so
I'm
starting
to
wonder
if
there
anybody
else,
for
you
wants
to
step
in
that
hasn't
had
a
chance
to
say
anything.
Yet
Raven
goes.
Who
are
you
doing
quite
late
in
the
call,
but
I
wonder
whether
you
had
anything
yeah,
no.
L
The
only
thing
I
was
going
to
add
is
that
we
learned
quite
painfully
over
the
years
that
the
most
reliable
way
for
this
to
work.
It
is
to
have
a
leasing
system
up
front
where,
when,
when
you,
when
you
start
the
booking
process
as
as
soon
as
you've
got
enough
information,
you
have
to
reserve
that
slot.
L
So
we've
we've
learnt
over
the
years
that
the
that
the
best
way
to
do
it
is
is,
is
for
you
to
treat
it
like.
It
is
a
theater
ticket
sale
where
you
have
to
reserve
the
seats
and
they're
reserved
for
a
certain
amount
of
time,
possibly
for
as
long
as
you
have
the
basket
active
and
then
only
once
it's
all
actually
paid
for.
L
There's
just
no
way
that
it
would
work
without
you
having
to
lease
those
spaces,
because
some
people
will
take
half
hour
45
minutes
for
them
to
finish
the
whole
purchase,
and
you
know
you
know
half-hour
45
minutes
everything
that
they've
that
they've
that
they've
put
into
the
basket
and
they
believe
that
they've
got
can
then
just
get
stolen
out
from
under
them,
and
they
just
massively
I
wrecked.
When
that
happens,.
D
That's
fantastic
feedback,
and
especially
on
the
timescales
there
could
I
I
mean
even
in
terms
of
what
we
recommend
as
a
lease
duration
in
the
spec
45
minutes
is
quite
a
long
time
to
have
the
item
held
for
by
a
by
a
user,
and
obviously
that's
is
interesting
because
on
the
Amazons
case
they
would
rather
obviously
get
that
sold
to
the
next
available
person.
But,
like
you
say,
if
that
creates
irate
customers,
then
it's
probably
not
something
right
off.
We.
We
really
want
here
so
interesting.
C
Just
to
echo
what
Raymond
said,
actually
we've
moved
to
a
two-phase
commit
to
set
payment
because
we
had
the
old
problem
and
you're
always
gonna.
Have
the
odd
problem
and
unpicking
it
when
you've
got
the
kind
of
two-step
booking
whatever
it
was.
We're
mean
that
you've
taken
the
money.
If
you
take
the
money
and
book
or
do
you
book
and
take
the
money
and
either
way
you
can
end
it
with
real
challenges
in
tracking
down
where
it
went
wrong
and
actually
know
if
it
did
go
wrong.
C
Obviously,
in
theory
all
your
arrows
are
captured
and
you've
got
someone
a
city
looking
through
the
logs,
but
let's
face
it
that
doesn't
happen.
So
the
first
thing
we
discovers
a
problem
that
you've
got
cross
customers.
Then
you
give
Chucky
down
so
I
think
you're,
two-phase
approach,
a
two-step
payment
is
essential
and
I
think
the
basic
sequence.
So
it's
kind
of
right
if
we
are
going
to
have
the
option
of
not
having
a
one
with
multiple
items
in
the
basket,
but
I
think
that
the
basket
was
neither
fully
succeed
or
fully
fail.
C
D
A
A
Wisdom,
so
much
density
is
great.
What
I'm?
What
I'm
wondering
is
how
how
we,
how
we
capture
this
in
a
way
that
everyone
feels
comfortable,
that
we've
dealt
with
a
variety
of
use
cases
reliving.
What
I've
heard
is
that
there's
a
variety
based
on
the
way
people
design
a
UX,
there's
some
stuff
around
how
you
know
back
office
toughest
handles
and
that
there's
some
probably
some
necessary
requirements
and
some
useful
variation
in
a
few
places.
A
So
if
we,
for
example,
just
put
together
a
shared
document
that
just
spell
out
and
all
of
these
different
variations
so
that
we
could
try
and
I,
you
know
more
clearly
identify
that
one
solution
or
another
is
going
to
tick
off
more
of
those
than
others,
or
at
least
demonstrates
that
we
found
a
compromise
with.
Would
that
be
a
useful
way
forward,
but
at
the
moment
that
we
just
kind
of
captured
a
requirement
for
at
least
without
really
kind
of
putting
any
context
around
it?
So
maybe
we
do
need
a
bit
more
information.
D
Potentially
we
could,
we
could
go
through
this
cool,
as
you
say,
and
document
all
of
that
into
into
some
bullet
points
share
that
round
and
then
maybe
in
another
call,
when
we've
got
that
presented,
we
can
present
that
back
as
a
yeah,
there's
pros
and
cons
table
or
if
it's
it
sounds
like.
Ultimately,
what
we're
talking
about
here
is:
do
we
made
the
lease
mandatory
or
optional,
because
it
sounds
like
there's?
Definitely
at
least
required
in
some
use
cases
really
want
that.
D
It
sounds
like
if
we've
based
on
that
decision,
there's
a
bunch
of
things
that,
like
William,
was
saying
about
complete
failure
or
complete
success,
that
we
need
to
make
sure
that
we
are
designed
one
of
those
to
correctly
take
into
account
everything
which
could
then
be
in
the
next
cause
discussion.
How
do
we
make
that
thing
work?
It
sounds
like
the
first
question
is
really
do
we
do
we
think
that
people's
disappointment
at
the
theater
ticket
question?
D
Basically,
is
you
know
how
to
what
extent
is
there
disappointment
over
that
kind
of
getting
to
the
end
of
the
process
and
not
succeeding,
and
and
if
we
think
that
that's
worth
making
a
mandatory
thing,
that
we
then
have
every
looking
system
implement
and
obviously
there's
a
cost
to
that,
but
it
might
be
worth
it
if
user
experience
is
worth
it,
then
maybe
that's
where
we
need
to
kind
of
be
really
clear.
So
these
are
the
pros
and
cons
in
that
way.
D
Every
time
we
work
with
a
new
booking
system
and
they
say
well,
I
know
if
we're
doing
these
two
calls,
we
can
say.
Well,
it's
a
really
well
documented
thing
here
that
says
these
are
all
the
reasons
and
actually
your
users
gonna
be
much
more
happy
and
your
customers
be
much
more
happy
and,
and
so
I
think
it's
it's.
It's
I
would
suggest
that
it's
fine
to
do
more
work
if
it's
well
justified
and
the
thing
whether
the
standards
thing
is
obviously
every
every
extra
bit
we'll
need
to
everyone.
D
A
D
A
Within
within
the
design
space
there's
we
can
find
way
so
that
leasing
is
like
the
leasing
calls
would
be
cheap
so
to
address
the
point
earlier
about
you
know,
a
couple
of
quick
calls
might
be
just
as
good
as
one.
You
know,
a
single
call
we
can
dig
into
if
there
is
tape
released
and
of.
What's
that
mean,
you
know
if
Ian
needs
to
implement
anonymous
releases,
then
aren't
what
are
the
options
for
doing
that
that
might
fit
meeting
current
workflows,
so
I
think
so.
A
L
Like
to
add
just
you
know,
just
a
last
point
on
it:
just
because
you've
got
a
lease
system
in
place
doesn't
mean
that
there
is
no
way
for
you
to
have
a
single
end
point
for
you
to
fire
and
forget
one.
You
know
one
in
one
single
booking
at
a
time
you
know.
So,
if
you've
got
all
of
the
you
know
all
the
places
in
place
for
you
to
have
a
lease
and
then
do
the
multistage
order.