Naime, uz svaki zahtev za plaćanje trgovac obavezno šalje parametar authentication.entityID kako bi nazad dobio referentni broj transakcije checkoutID. Tipičan primer ovog zahteva se nalazi ispod:
curl https://test.oppwa.com/v1/checkouts \ -d "authentication.userId=8a8294184f45ce7e014f4b1d16cc12df" \ -d "authentication.password=j3zCJ2ENaD" \ -d "authentication.entityId=8a8294184f45ce7e014f4b1d16bd12db" \ -d "paymentType=DB" \ -d "amount=100.99" \ -d "currency=RSD"Postoji mnogo različitih scenarija zbog čega je korisno zapamtiti ovaj authentication.entityID. Jedan primer je trgovac kome je dodeljeno više kanala (entityID) za plaćanja, gde jedan kanal koristi za inicijalnu transakciju i registraciju kartice, a drugi kanal za one-click plaćanje registrovanom karticom. Slično je i kada trgovac na jedan kanal šalje transakcije ka jednoj banci, a na drugi kanal transakcije ka drugoj banci. Za svaki dodeljeni kanal, trgovac dobija authentication.entityID. U takvim situacijama trgovac treba zapamtiti entityID koji je korišćen kako bi kasnije mogao da izvršava REVERSAL ili CAPTURE transakcije.
Takozvane back-office transakcije, kao što su REVERSAL, CAPTURE, REFUND itd, zahtevaju da se uz zahtev šalje isti entityID kao i kod inicijalnog uspešnog plaćanja. Razlog za ovo je što sistem mora znati gde (na kom kanalu) je izvršena konkretna transakcija plaćanja. Ukoliko bi poslali zahtev za REVERSAL na pogrešan entityID sistem bi vratio odgovor sa greškom: 700.400.700 - Initial and referencing channel-ids do not match .