Production Update 1.2.8
Summary
Closes the four items still open after the 27 September retest of 1.2.7: a cashier shift can be created, Super Agent and Agent share one set of names, a support ticket can carry a screenshot, and a transfer stuck on the way into a game can be closed from Admin. Image limits on tickets, and a few screen fixes next to the new names, were added on top of those four items.
Added
- Credit correction sits next to Debit correction on a Player, Shop, Agent, or Super Agent. It posts funds onto that wallet. It does not by itself close a stuck game transfer.Module: Wallet corrections · Portal: Admin
- A player or a support reply can attach JPG, PNG, or WEBP screenshots. Defaults are under 5 MB, 2 images per message, and 10 player images per ticket per day. Admin → Tickets → Image limits changes those three numbers for new screenshots.Module: Support tickets · Portal: Player, Admin
Changed
- A shift is saved with a cashier and a time. The counter is recognised at sign-in, approved by a four-character code or a pairing code, and bound when the shift starts. Deposits, redemptions, cash drops, handover, and ending the shift run only on that counter.Module: Cashiers · Portal: Shop, Cashier
- Super Agent and Agent use one name for each page, balance, and money action. The landing page is Dashboard. Credits show as credits. USD keeps a dollar sign. Sign out replaces Log out. Cash transactions opens on Today.Module: Navigation · Portal: Super Agent, Agent
- On a deposit into a game, Check status reads that game row against the parent deposit and the game-wallet record. Staff can set an open row to completed or failed. The check does not move money.Module: Deposits · Portal: Admin
- A transfer that never reaches the game is failed after 30 minutes and the credits return to the player wallet. A transfer the game provider has already started is left alone.Module: Game wallets · Portal: Player, Admin
- A later retry does not send a game credit again after the provider has already recorded it. An open payment row is marked completed. Failed, cancelled, expired, and rejected rows stay as they are.Module: Deposits · Portal: Admin
Affected Modules
- Cashiers
- Shifts
- Navigation
- Support tickets
- Deposits
- Game wallets
- Player ledger
- Wallet corrections
Affected Portals
- Admin Portal
- Super Agent Portal
- Agent Portal
- Shop Portal
- Cashier Portal
- Player Portal
Issue status
The 27 September retest of 1.2.7 left four items open. All four are closed in this build. A few things were added on top of those four. They are marked Also added in the table, and written out in the section for that item.
| # | What the retest asked for | Status |
|---|---|---|
| 15 | A cashier can be given a shift. The counter is recognised at sign-in | Done. Also added: approve with a pairing code, move the shift to another counter, block a counter, and a list of wrong-device attempts |
| 35 | One name per page and per money action in Super Agent and Agent | Done. Admin keeps its current labels. Also added: Cash transactions opens on Today, a credit balance has no dollar sign, and the phone layout keeps the labels readable |
| 53 | A player and a support reply can attach a screenshot to a ticket | Done. Also added: Image limits (size, images per message, player images per ticket per day), a viewer, and an unsent image expires after 1 hour |
| 54 | A transfer stuck on the way into a game can be closed from Admin, including a refund to the wallet | Done. The row can be checked, a transfer that never reaches the game returns after 30 minutes, and Credit correction sits next to Debit correction. Also added: a later retry does not send a credit the game already has |
15. A cashier shift, and the counter it runs on
Where: Shop → Cashiers → Shifts and Devices. Cashier app → My shifts, on the website or the Android app.
Previous issue: Creating a shift asked for a device that was already approved. Signing in as a cashier did not register the counter, so Devices stayed at zero and no shift could be saved. 1.2.7 left this open.
What the retest asked for: The cashier app registers the counter at sign-in, so a shift can be created. A browser sign-in and the installed app both count. There is no separate registration step.
What we did: The shift is the cashier and the time. The counter is recognised when that cashier signs in, and the shift binds that counter at Start shift. Money actions then run only there. On top of that request, the shop can approve the counter with a pairing code, move a running shift to another counter, block a counter, and see refused attempts under Fraud indicators.
After the update:
Schedule the shift (Shop)
Cashiers → Shifts → Schedule shift (or the same action on a cashier).
- Pick the cashier, the date, and the start and end time.
- Device (optional) stays on Any approved device (chosen at start) unless this shift must run on one named counter. If the device list does not load, you can still save with that choice.
- Press Schedule shift. Saving does not need a device.
A shift that says Starts on and then the device name can start only on that counter. To allow any approved counter, leave the device on Any approved device.
Two shifts cannot use the same cashier at the same time. Two shifts cannot run on the same pinned counter at the same time. The page says the times overlap.
What the cashier sees
Sign in on the counter, in the cashier website or the installed app. There is no separate “register this device” step. The sign-in itself is the registration.
My shifts has a This device card:
| The card | What it means | What to do |
|---|---|---|
| Approved · the device name | This counter is approved. Shifts can start here. | Press Start shift on the scheduled shift. |
| Waiting for approval · Code, then four characters | The shop has not approved this counter. The code looks like 7F3A. | Show the code to the manager, or type the pairing code they read out. |
| This device is blocked. Ask your manager. | The shop blocked this counter. | Use another counter, or ask the manager to unblock it. |
| This device is not recognized. Sign in again. | This session has no counter. A cashier who was already signed in before this update sees this once. | Sign out, then Sign in again on this counter. |
If the counter still needs approval at sign-in, a note says this device needs approval before starting a shift.
Start shift
- Press Start shift. The check-in time is saved at that moment. A cashier who has checked in is not marked no-show while waiting for the device to be approved.
- If the card says Approved, count the opening cash and confirm. The button on that count is also Start shift.
- If the card is waiting, the screen says Waiting for your manager to approve this device. It continues on its own when the manager approves. You do not have to start again.
- Or, under Have a pairing code?, type the code the manager gives you. It is shown as
XXXX-XXXX. Press Pair device. While it checks, the button reads Checking….
A running shift uses Continue shift. A finished, locked, or suspended shift uses View shift. Ending the shift uses End shift.
Approve the counter (Shop)
When a cashier is waiting, Cashiers and Devices in the menu show a count.
From the office, Cashiers → Devices:
- The new counter is under Waiting for approval, with the cashier and the shift.
- Match its four-character code with the code on the cashier’s screen. Approve only when they match.
- Press Approve, type a name staff will recognise (for example Counter 1), and confirm. The name is 1 to 64 characters. The cashier’s screen continues on its own.
- If you cannot confirm the code, press Reject.
At the counter, Devices → Add device with pairing code:
- You can type the device name first. You do not have to.
- Read the code to the cashier. It looks like K7QM-3XPD. It works once and expires in 10 minutes. The page counts down the time left.
- The cashier types it and presses Pair device. The counter is approved immediately.
A shop can have 5 pairing codes open at once. The sixth says you already have 5 open pairing codes. Use one, or wait until one expires.
On the same Devices page:
| Action | What it does |
|---|---|
| Rename | Changes the name staff see. The counter stays approved. |
| Block | Signs that counter out. It cannot take deposits, redemptions, cash drops, a handover, or the end of a shift. |
| Unblock | Approves that counter again. |
During the shift
Deposits, redemptions, cash drops, handover, and ending the shift work only on the counter the shift started on.
Signing in on a different counter shows the shift, and the money buttons do not run there. The message is that your shift is running on the named device. Deposits, redemptions, cash drops, and ending the shift only work there.
If that counter breaks, the manager opens the active shift and presses Move to another device.
- Pick an approved device that is not already running a shift.
- Enter a reason of at least 3 characters. It is kept with the shift.
- The cashier signs in on the new counter and presses Continue shift. The old counter can no longer take money for this shift.
Move to another device stays disabled until both the new device and a long enough reason are filled in.
Cashiers → Fraud indicators → Wrong-device attempts lists each money action that was refused because it was not on the shift’s counter: the cashier, the action, the time, and the shift.
Messages you may see
| Who | Message | What to do |
|---|---|---|
| Cashier | Waiting for your manager to approve this device | The manager matches the code under Devices, or reads out a pairing code. |
| Cashier | The pairing code is wrong or expired. | Codes work once and last 10 minutes. Ask for a new one. |
| Cashier | Too many wrong codes. | Wait, or ask the manager to approve from Devices. The portal approval still works. |
| Cashier | This shift must start on the named device. | Use that counter, or the manager sets the shift back to Any approved device. |
| Cashier | Another shift is running on this device. | That shift has to end first, or start on another counter. |
| Cashier | You already have an active shift. End it before starting another one. | Press End shift on the open shift first. |
| Shop | That device is not approved. | Pick another device, or Any approved device. |
| Shop | Another shift is running on that device. | Pick a counter with no active shift. |
| Shop | Device name must be 1–64 characters. | Shorten the name. |
35. Super Agent and Agent: one name on the page, the menu, and the buttons
Where: Super Agent portal and Agent portal. The menu, the page heading, the breadcrumb, the balance cards, the money dialogs, and sign-in.
Previous issue: 1.2.7 left the same screen with a different name in each portal. On Agent, the role above you was written three or four ways (super agent, Super agent, Super Agent, SA). The first page was Home in one portal and Dashboard in another. A credit balance could show a dollar sign. Cash transactions opened on 30 days in one place and on Today in another.
What the retest asked for: One name for each page and each money action, and one way of writing each role. The payment list, the first page, and the Super Agent role were the examples that still differed.
What we did: Super Agent and Agent now use one name for each page and each money action. The name in the menu is the name in the heading and in the breadcrumb. Amounts did not change. A credit is still a credit, and a dollar is still a dollar. On top of the new names, Cash transactions opens on Today, a credit balance is shown as credits, and the phone screens keep those labels fully visible.
The Admin portal keeps its current labels, including Credit Wallets, Cash Transactions, and Log out. Shop and Cashier received the same naming pass. The detail below is what a Super Agent and an Agent see.
An old address that used to open the first page still opens Dashboard. On Super Agent, /dashboard opens the page at /.
What both portals show
Sign-in says Sign in. The password link is Forgot password?. The way back is Back to sign in. The account menu says Sign out. Log out is gone. Signing out returns you to the sign-in page.
Statuses read as words: Active, Suspended, Terminated, Banned. They are not shown as ACTIVE or as a raw code.
| What you are doing | The name on the button and the page |
|---|---|
| Pay crypto into your own USD wallet | Add USD |
| Turn USD wallet balance into credits | Buy credits |
| Give credits to the tier below, for cash | Sell credits |
| Take credits back from the tier below | Withdraw credits |
| Send your USD wallet out to crypto | Request payout |
| Open the credit ledger | Credit transactions |
| Open the cash ledger | Cash transactions |
| Open the USD ledger | USD wallet transactions |
| Open fees | Fee configuration |
| Turn a suspended account back on | Reactivate |
The two balance cards:
| Card | How the number looks |
|---|---|
| Credit balance | 1,250 credits, or 1 credit when the balance is exactly 1. No dollar sign. If the credit balance cannot be loaded, the card shows —, not zero. |
| USD wallet balance | $1,234.56, always with a dollar sign and two decimals. |
Cash transactions opens on Today. Export follows that. Choose 30d and Apply when you want a longer list. Leave the page and come back, and it is on Today again. Credit transactions and USD wallet transactions already opened on Today. Cash transactions now matches them.
The filter button is Apply.
Super Agent
The sign-in heading is Super Agent portal, with Super Agent sign-in under it. The footer is Kiosk Gaming · Super Agent portal.
After sign-in the sidebar is, in this order:
Dashboard, Agents, Shops, Players, Credit transactions, Cash transactions, USD wallet transactions, Fee configuration, Fraud indicators, Popups, Broadcasts, Settings.
Popups and Broadcasts are hidden when this Super Agent cannot send them. The page buttons stay Send popup and Send broadcast.
The phone bottom bar is Dashboard, Agents, Shops, Players. On a phone, the Dashboard tabs (Overview, Financials, Agents, Roadblocks) scroll sideways inside the tab strip. The rest of the page does not slide sideways. A wide table can still scroll inside its own box.
| You used to see | You see now |
|---|---|
| Overview, as the name of the first page | Dashboard. The first tab inside Dashboard is still called Overview. |
| Page, in the breadcrumb on Cash transactions, Fraud indicators, and Settings | The real page name, for example Cash transactions or Settings |
| Provider fees | Fee configuration |
| Create agent, with no Agents step in the breadcrumb | Create Agent, and the breadcrumb is your name › Agents › Create Agent. Agents stays highlighted. |
| A credit balance like $1,250.00 | 1,250 credits |
| Log out | Sign out |
| Unsuspend | Reactivate |
| ACTIVE, or active, on a badge | Active or Suspended |
| Cash paid up-chain, CDN, SA, in the Financials explanations | Cash paid to the Platform, and Super Agent written in full |
Sell credits on an Agent is titled Sell credits. The flow reads Super Agent → Agent. The fields are the credit amount, the cash received, and an optional reference. The success message is Credits sold.
Withdraw credits is titled Withdraw credits from Agent. Credits leave that Agent’s wallet and come back to your Super Agent balance.
Buy credits uses the USD wallet. The preview is the dollars you typed, divided by your cost rate, as a number of credits. The success message names the credits and the dollars.
The breadcrumb starts with your name, then the page. An Agent’s page is your name › Agents › Agent details, and Agents stays highlighted. A Shop’s page keeps Shops highlighted.
Agent
The sign-in heading is Agent portal. The app name is Agent portal — Kiosk Gaming.
The sidebar is:
Dashboard, Shops, Players, Credit transactions, Cash transactions, USD wallet transactions, Fee configuration, Fraud indicators, Popups, Broadcasts, Settings.
Popups and Broadcasts show only when this Agent is allowed to send them.
The phone bottom bar has four labels, all fully visible: Dashboard, Shops, Players, Transactions. Transactions is only the short label on the phone. It opens the page headed Credit transactions. On a computer the same item is Credit transactions.
| You used to see | You see now |
|---|---|
| Home, or Back to Overview | Dashboard, and Back to Dashboard |
| Transactions, Credit wallet transactions, or Credit wallet tx | Credit transactions on the page, the menu, the Dashboard link, and a Shop’s credit tab |
| super agent, Super agent, SA, up-chain, upstream, or hierarchy | Super Agent, in those two words, including inside the small (i) explanations |
| Credits purchased, used for two different numbers | Credits bought for what you paid your Super Agent. Credits sold for what your Shops paid you. |
| Shop pulse and money at a glance, under the Dashboard heading | Your Shops and money at a glance |
| Unsuspend | Reactivate. The message is Shop reactivated. |
| User name, on Create Shop | Username |
| Seller and Buyer, on Cash transactions | From and To |
| Nothing highlighted when you open a Player | Players stays highlighted on that Player’s page, on a computer and on a phone |
Sell credits gives credits to a Shop for cash. Withdraw credits takes credits back from a Shop. Add USD and Buy credits are the two buttons on Dashboard → Overview, and the two tabs of the same dialog. On USD wallet transactions, the type for that purchase reads Buy credits.
Suspend a Shop asks Suspend this Shop? The warning says the Shop cannot sign in or operate until you reactivate it, and that active sessions may stop. The buttons are Cancel and Suspend Shop. A suspended Shop then shows Reactivate.
53. A screenshot on a support ticket
Where: Player app → support, on a new ticket and on a reply. Admin → Tickets, on a reply and on Image limits.
Previous issue: The 27 September retest found no way to attach an image on either side. The reply box had no attach control, and a player opening or answering a ticket could not attach one either. A deposit or withdrawal dispute is decided from a screenshot, so both sides need to put one on the ticket.
What the retest asked for: The player can attach a screenshot when opening a ticket or when replying. Staff can attach one on a reply.
What we did: Both sides can attach an image, and the thread shows it. On top of that request, Admin can set how large an image may be and how many may be sent, the image opens in a viewer, and an image that was chosen but not sent expires after one hour.
After the update:
What the player does
- Open a new ticket, or open a ticket you already sent, and start a reply.
- Tap Add screenshot and choose an image.
- The image appears on the message before you send. Remove screenshot takes it off if you chose the wrong one.
- Send the message. The image stays on that message in the thread.
English and Spanish use the same steps.
Tap an image in the thread to open it. Previous screenshot and Next screenshot move through the images on that message. Close leaves the viewer. Copy link copies the image address. The button then reads Link copied.
An image you add but do not send expires after 1 hour. Add it again if you come back later.
What image is accepted
| Rule | What you see |
|---|---|
| File type | JPG, PNG, or WEBP only. A PDF, a video, or a renamed file that is not really one of those three is refused: “Use a JPG, PNG, or WEBP image.” |
| Size | Each image must be under the size limit. A file that is exactly the limit is refused: “Each image must be under 5 MB.” The number follows the saved limit. |
| How many on one message | Up to the per-message limit. One more than that reads: “You can attach up to 2 images to one message.” The number follows the saved limit. |
| How many the player may add on one ticket today | The daily cap. The form shows how many are left, for example “8 of 10 left on this ticket today.” At zero it reads that today’s limit on this ticket has been reached. |
The file itself is checked. Changing the name to .jpg does not make another kind of file acceptable.
Image limits (added on top of the request)
The retest asked only for an attach control on both sides. Image limits is the extra control, so staff can change the size and the counts without a new release.
Where: Admin → Tickets, the Image limits button at the top of the queue, next to Shortcuts.
Staff who can manage tickets open it, change the numbers, and press Save. Cancel closes the dialog and keeps the old numbers. A successful save says “Attachment limits updated.”
The dialog says the new numbers apply to new screenshots. Images already on a ticket stay as they are.
| Field on the dialog | What it controls | Allowed value | Starting value |
|---|---|---|---|
| Max size per image (MB) | The largest a new screenshot may be. The file must be under this size. A file of exactly this size is rejected. | A whole number from 1 to 5 | 5 |
| Images per message | How many images one message may carry, for a player and for a support reply | A whole number from 1 to 5 | 2 |
| Player images per ticket per day | How many images a player may attach to one ticket during one day | A whole number from 1 to 50, and it cannot be lower than Images per message | 10 |
The daily count uses the support timezone, which is US Eastern unless the platform has set another zone. The day starts at midnight in that zone. Support replies are not counted in the player’s daily number. A player who has used the day’s images can still receive images from staff.
If the daily number is set lower than the per-message number, Save is refused. The daily limit cannot be lower than the per-message limit.
The player form reads the saved limits, so after Save the next ticket the player opens shows the new size, the new per-message count, and the new daily count.
54. A transfer stuck on the way into a game
Where: Admin → Payment transactions, and Admin → the Player, Shop, Agent, or Super Agent page
Previous issue: The 27 September retest found a wallet-to-game transfer that took the credits off the player’s wallet and then stayed on “Game sync” with no end. The credits never arrived in the game, and they did not come back. Other failed transfers had returned on their own. This one did not time out. The panel had no way to cancel that transfer or refund it. The only correction on the player was Balance Correction — Debit, which takes money off the wallet. Putting the player back required the vendor.
What the retest asked for: Three controls, so staff can close the case from the panel.
- On that pending transfer, cancel it and refund the credits to the wallet.
- If the transfer cannot reach the game within a set time, fail it and refund on its own, so it does not hang with no end.
- A credit correction on the wallet, matching the debit correction that was already there, so staff can return funds and not only claw them back.
What we did: All three are in this build. The sections below say which button does which job. On top of the request, Check status can set the row to completed or failed without moving money, and a later retry does not send a credit the game already has.
| The situation | What to use | What happens to the money |
|---|---|---|
| You need to know whether the game already has the credits, and to close an open row | Check status on that game row | The status changes. The wallet does not |
| The transfer has been waiting 30 minutes and the game was never contacted | Nothing. The timeout does it | The credits return to the player’s wallet |
| The player, shop, agent, or super agent should receive funds on the wallet itself | Credit correction | That wallet is credited. The game row is not closed by this button |
A deposit that is split across games has one row per game. The steps below are about that game’s row, not the whole deposit, unless the deposit was for one game only.
1. Check status on that transfer
Who: System Admin, Super Admin, Finance Admin, and Operation Admin.
Where: Admin → Payment transactions. Open the deposit, or on the list press Show game allocation rows. An open game row has Check status.
Check status is not offered when that row is already completed, failed, rejected, or already refunded.
- Press Check status.
- The dialog title is Check allocation status. It says the check compares this row with its parent and the game-wallet transaction, and that this check does not move wallet funds.
- Read the three lines: This allocation, Parent transaction, and Game-wallet transaction. Each line shows its number and its status. If a line has no record, it reads No row.
- The dialog then says one of three things.
| What it says | What it means | Button |
|---|---|---|
| Change status to completed | The game already recorded the credit, and the payment row is still open | Set status to completed |
| Change status to failed | The game did not receive the credit, and the payment row is still open | Set status to failed |
| Keep the current status | The game is still working, the credit has not finished, the row was already refunded, or the row is already completed or failed | Close only |
- Close leaves the row as it is.
- Set status to completed or Set status to failed writes that status. The toast says the status was set. The dialog notes who should see it as updated. The record stores who pressed it and what the status was before.
While the game-wallet line is still processing, the dialog keeps the current status. The provider may already have been called, so the payment status is left as it is. Do not treat that row as money you can take back from this dialog.
Check status does not return credits to the wallet. Marking a row failed records that the transfer did not complete. Putting the credits back is the timeout below, or Credit correction.
If the game has already recorded the credit, a later automatic retry does not send that credit again. An open payment row in that case is set to completed. A row that already ended as failed, cancelled, expired, or rejected stays on that status. It is not pulled back to completed.
2. A transfer that never starts comes back after 30 minutes
Who: Nobody has to press a button. This runs on its own.
When it returns the credits: The game row is still open (pending, processing, or waiting to retry), it is older than 30 minutes, and the game provider was not already called. The credits go back to the player’s wallet. The amount is the amount of that game row. The parent deposit is not rewritten as a second payment.
The row stores the reason Automatic timeout: game sync did not start. On the game row, staff see the refund reference once the return has been written.
When it does not return the credits:
- The game provider is already being called for that row. Wait until that attempt finishes or fails. The timeout will not take the money back while that call is in progress.
- The game already received the credits. Those stay in the game.
- The row was already refunded. It is not refunded a second time.
So a transfer cannot sit open forever when the game was never contacted. After 30 minutes the player’s wallet has those credits again.
That automatic return is the same refund as cancelling one pending game row: the row is no longer pending, and that row’s credits are back in the player’s wallet. It runs only for a row the game has not started. Staff do not type a reason for the timeout. The reason on the row is the automatic one above.
Check status is the control on that row in this build. It can mark the row completed or failed. It does not, by itself, move the credits. To put credits on a wallet before the 30 minutes are up, or after the game was already contacted, use Credit correction in the next section. If the game row is still open, mark it with Check status as well.
3. Credit correction: put funds back on a wallet
Who: System Admin, Super Admin, and Finance Admin who can manage wallets. The buttons are hidden on a terminated account.
Where: Open the account and use the actions on that page.
| Account | Buttons |
|---|---|
| Player | Credit correction and Debit correction |
| Shop | Credit correction and Debit correction |
| Agent | Credit correction and Debit correction |
| Super Agent | Credit correction and Debit correction |
Debit correction was already there. It takes funds off a wallet that were already posted. Credit correction is the matching action in the other direction. It puts funds onto the wallet.
Credit correction opens a dialog titled Balance Correction — Credit. The dialog says this posts a ledger credit and returns funds to this wallet. It also says this is not the same as closing a stuck transfer into a game. If a transfer is still waiting on the game, use the game row (Check status, or the 30-minute return). Credit correction does not cancel that game row, and it does not unwind the balance the game transfer is holding.
Fill in the dialog:
| Field | What to enter |
|---|---|
| Wallet | On a player, the wallet is CDN credits. There is no USD correction on a player. On a Shop, Agent, or Super Agent, choose CDN credits or USD wallet. The dialog shows the available balance of the wallet you chose. |
| Amount | A number greater than zero. Example placeholder: 100.50. |
| Ticket / incident id | Required. At least 3 characters. This is the support ticket or the incident you are fixing. It is stored with the correction. |
| Reason | Required. At least 10 characters. For a credit, describe why these funds are being returned. |
Press Apply credit. While it saves, the button reads Applying…. Cancel closes the dialog and posts nothing.
The wallet balance changes as soon as Apply succeeds. There is no undo button on this screen. The ticket and the reason are kept for the audit.
Press Apply once. If the same request is sent twice, the wallet is credited once. Close the dialog and open Credit correction again if you mean to post a second credit. Opening the dialog again is a new correction. The same ticket id does not block that second post.
Debit correction still opens Balance Correction — Debit and Apply debit. For a player, the amount cannot be higher than the available balance (the total minus what is already reserved). The screen says so if the amount is too high. Credits taken from a player go back to the platform. They are not sent to that player’s shop wallet.
Use Credit correction when the wallet itself should be higher: a mistaken clawback, a case the 30-minute return did not cover because the game had already been contacted, or any approved return that is not “cancel this game row.” If the game row is still open, close it with Check status as well, so the payment row and the wallet tell the same story.