Recommended flow for using Google Wallet with complex custom digital goods

Recommended flow for using Google Wallet with complex custom digital goods

I'm trying to set up a google wallet payment process for users to purchase
an entry into a tournament. In order to do this, the user has to fill out
a bunch of information about themselves (name, league player number,
contact phone number, etc), and there are some other pieces of data that
are implicit, such as a unique identifier for the tournament they're
entering.
It seems like there are two ways to accomplish this in Google Wallet, and
I'm wondering if I'm missing another, better workflow and/or if one of
these two ways is preferred.
Possibility #1
When the user clicks the wallet button, I serialize the form and submit it
to my server using ajax. If the form is properly filled out, the server
encodes everything about the form into the sellerData field of the JWT,
and returns the JWT asynchronously. I then pass this JWT to wallet,
expecting to receive it in my postback handler.
The postback handler then constructs the entry using the information from
the JWT sellerData field and records it in the database.
This possibility is intuitive to me, and I've implemented it, but I'm
running up against the 200 character limit for the sellerData field, since
it contains multiple peoples' names, phone numbers, and various other form
elements. There's just no room. I don't have a workaround for this, and
would welcome thoughts.
This approach has the advantage that nothing is created in my database
until payment is successful, but I don't know how to work around the
difficulties with representing the entire form in the JWT to get it to the
postback handler somehow.
Possibility #2
The user just submits the entry form using the normal web-form submission
process, which creates something in the database. Database objects newly
created in this way are marked as "unpaid", and are therefore incomplete.
Once the user successfully creates their entry in the database, they are
then presented with a second page at which they can pay. This works better
because I can now just put the database key for the object they just
created into the sellerData field, and not worry about the size limit.
It does have the unfortunate side-effect of having these half-completed
objects in the database, as well as running the risk of users not quite
understanding the two-step register-and-then-pay process, and forgetting
to pay. I'd have to be quite careful and proactive about making sure that
users realize that A) it's okay to submit the form with no payment
information, and B) that submitting the first form doesn't mean that
they're done.
Thoughts?