[#75] The AI Money Movement Layer (Part 1): MCP, ACP & TAP are launched but are autonomous payments really the future?

Protocols launched by OpenAI, Stripe, Visa and Google (AP2) suggest that autonomous payments are the future, but some protocols are mandates hiding behind A, while 2FA requirements may hinder others.

The big talking point over the last month has been the launch of agentic payments. There are 4 things that stand out for me:

1. Razorpay launched Agentic payments on UPI through OpenAI - allowing users to make payments at the Global Fintech Fest in 2025

2. Google’s Agentic Payment Protocols (AP2), which allow mandates to be stored in a “trust layer” which is AP2, and in real time, compare payment requests to stored mandates for payment processing were launched in September 2025

3. The OpenAI & Stripe Agentic Commerce Protocol launch, to integrate “instant checkout” within the ChatGPT interface in September 2025

4. Visa launched the Visa Trusted Protocol for agentic commerce, which allows agents to initiate payments & reference stored credentials (like tokenized cards) on the end users behalf, without asking for consent again in October 2025

Now, the end goal of all these protocols are the same: allow the agent to initiate and process payments on behalf of the customer. But the ways that the players have chosen to implement these are slightly different.

At the crux: these are the following questions / pain points that these players have all tried to solve:

Commerce within the LLM Chat: The thought process being that if all commerce & shopping is going to happen on the LLM chat, then why should payments be any different, and the experience should be: to provide a way to initiate and complete payments within the LLM Chat, by simply “sending a request in the LLM chat.” Cool. So then, just from a first principles perspective, a few things need to happen:

1. The order request is placed through the LLM chat, which has provided catalogue level details etc through the merchant MCP (Model Context Protocol for the uninitiated - a set up standardized APIs & endpoints that the LLM can use to communicate with the merchant).

2. After the order request is placed, this order request needs to be converted into the merchant “cart,” and the merchant’s payment processor needs to create an Order ID, and make subsequent API calls to the merchant’s payment processor. So, now for this, there needs to be some sort of translation layer that enabled the order request to be converted into a cart order and a payment request

3. After the payment request is created, the payment method needs to be selected, and the payment needs to be authenticated. Now, the method selection is easy, but payment authentication is where the crux of the issue sits.

4. Now, if 2FA is not mandated, then it becomes a 1 click payment, where stored credentials saved at the merchant can be referenced. So here, some sort of permission or flow is needed, where the LLM chat hits the merchant MCP → which creates the payment request → to authenticate the payment, the stored credentials are referenced through the merchant or some sort of flow. This is a little more agentic, because it requires limited human intervention

5. If 2FA is mandated, then it becomes tricky, because there is some entry that the end customer needs to do: either through biometric credentials, or through PIN, or through OTP, or something else. And entering these credentials into the LLM chat is something that is NOT recommended. In fact, even when you’re setting up backend auth for your merchant services, it is recommended NOT to share your private key with the LLM, just the public key, that it can use to reference the private key of the service that you’re using. So then, this will require some sort of native / embedded SDK flow, or a redirection, and this is not something that the agent can add, so human intervention will be required.

Below is the flow of authentication for card payments & UPI payments. In India, 2FA is mandated, so card payments have the card itself & the OTP. While UPI payments have the device & the PIN.

Authentication in card payments → 2FA means OTP entry is needed

Authentication in UPI → PIN entry is required which is a user input at every transaction

So immediately, the thought that comes to mind is that flow works for countries like the US and EU where 2FA is not mandated. And as a refresher: 2FA means that the user needs to authenticate 2 out of the 3:

• Something you have: Tokenized card, OTP (device). Something you have is the easiest, where you can used tokenized card details and process the payment.

• Something you know: PIN / Password / CVV

• Something you are: Face ID, fingerprint

So, now, lets unpack what is actually happening in the four launches that I called out in the above flow:

1️⃣ Razorpay launched AI Payments on UPI through OpenAI & Claude at GFF 2025

Original link to Razorpay launch video here

Let’s unpack what is happening in the above video.

1. The user asks Claude to reorder their protein powder from Bigbasket. I’m assuming here, the LLM (Claude) is speaking to BigBasket directly. So I’m assuming Claude has integrated with BigBasket (either standalone or through some MCP gateway) in order to call its APIs

2. Claude finds the BigBasket order and passes the payment request

3. The payment request is sent to Razorpay where Razorpay places the order using UPI Reserve Pay. Again, this is done now using the Razorpay MCP. And the payment is successful.

Some takeaways:

1. There doesn’t seem to be any authentication happening here, just that the payment has been done through something called UPI Reserve Pay. So I assume the authentication has already happened somewhere.

2. UPI Reserve Pay is similar to UPI Autopay, in the way that it needs to be pre-authorized. But where it is different is that it sets up a payment block, versus a fund transfer instruction in Autopay. UPI Autopay is a one time mandate registration for recurring debits.

   1. UPI Reserve Pay is a way of paying where you can do the authorization one time, and the money gets blocked in the account to use whenever the merchant “captures” the money. This is different from the case of UPI Autopay, where there is a standing instruction to transfer funds, the funds aren’t blocked. So in UPI Autopay, there is risk of failure, since at the time of mandate triggering, funds have to be present in the account. UPI Reserve Pay is more like saying: “Hey - block INR 15k in my account, which I’ll use to spend on a merchant - lets say Blinkit. And authorize this at the time of set up. So when the payment is triggered on chatGPT using UPI Reserve Pay, the money is debited from the funds that were blocked earlier. the UPI Reserve Pay seems to be a combination of UPI Autopay (in the case of mandate registration, which requires authentication at the time of set up), and Single Block Multi Debit, which allows funds to be blocked at one time, and multiple debits to happen from it. So this answers the question in point 1: authorization has happened for this payment already.

✅ Takeaway: Reserve pay is pre-set up at the merchant, and at a merchant level. So for the user to use this method to transact through a LLM chat, the user first needs to go and set this up at the specific merchant, against which debits can be made. So this only makes sense for merchants you know you transact through regularly, because then its worth the effort of going and setting this up. And remember, setting this up through the LLM chat, in India atleast will be tough because of the 2FA requirement, and the constraint of UPI payments happening only through the mobile (embedded CL in the app which powers the page that does PIN entry).

❓Open question: If this is a merchant I user frequently, then why not just use the merchant app, especially if I’ve gone through the effort of setting up reserve pay for it? Why go through the LLM chat? What AI does is personalizes experiences, especially if the ask and the question is ambigious. I guess we will see how customer behaviour evolves.

Note: Think of MCP as a translator layer, it allows the LLM chat to call the 3rd party APIs seamlessly. Once a 3rd party has integrated with the MCP, it has to register with the LLM, so the LLMs know what to call, to initiate any action on the merchant. And, there will be 2 layers of MCP. If we decouple the experience into shopping and payments, shopping will require the merchant MCP for catalogue access. But payments will require the merchant x PA MCP (assume Razorpay, Cashfree). I’m assuming the MCP here will be merchant specific, but PA hosted, since the PA will be processing the payment.

Just as a side note: there are interesting things that will be built on the orchestration & API standardization side to support agentic commerce. Example:

1. A MCP x Payment orchestration layer: Today payment orchestration happens to select the best performing PA. Now, with the MCP layer in the mix, You can route at the MCP level to whichever PA has:

   • Highest success rate for that payment method

   • Best experience for a given merchant segment

   • Least latency / timeout issues

Example: Agent → MCP Orchestrator → Best performing PA MCP endpoint → Merchant

2. One integration with a gateway layer = integration with all LLMs: So if you’re a merchant or a PA, and you want your store or payment rails to work with all these platforms, you’d have to build for OpenAI’s MCP, build again for Claude’s MCP, and then again for Google’s MCP. That’s multiple builds, multiple formats, and a huge operational load. Enter the gateway layer. This is a single tech layer that sits between the LLMs and the merchant/payment ecosystem.

   • Merchants and PAs integrate once with the gateway.

   • The gateway connects to all the different LLM MCPs.

   • It handles translation, standardization, and routing automatically.

   So whether the request comes from OpenAI or Claude, the merchant only sees one standardized format. And they don’t have to rebuild every time a new LLM or MCP variant appears. But that’s a separate topic.

2️⃣ Google Agentic Payment Protocols Launched (AP2) for mandate based agentic payments payments

AP2 doesn’t move money. This is important to understand. Like it was with the AI payments launch on UPI, it is essentially a mandate, hiding behind AI. What Google has done is created another layer that allows one time mandate set up, and then payment / order instructions translation & comparison against the mandate.

1. So the agent (Claude, Gemini ChatGPT, etc.) gets the payment instruction. It then sends this to → AP2. Note, at the first time set up, there has been some sort of auth, which creates, and stores the mandate at the AP2 layer. So, when the payment instruction comes in, it is mapped against stored mandates at the AP2 level, and then executed, or not executed.

2. Then AP2 stores and manages these mandates, like a vault of agent-managed instructions. When the trigger conditions are met, it passes that instruction to the merchant and PA, which executes the actual payment, which then becomes your regular money flow, where it calls either the network, or the UPI APIs which first check the auth that had been set up, and then process the money flow, by sending instructions to the issuer and the acquirer banks.

This is how I’m assuming it’ll work in real time for a fully autonomous payment

• The user has already consented to a standing mandate (e.g., “up to INR 2,000 monthly for reorders from let us say BigBasket”), using the PIN, or OTP or something else to authenticate.

• This was pre-verified once, during setup (AP2 recorded the explicit consent + PA validated it).

• When the condition is met, i.e, I reorder from BigBasket, or from the LLM Chat, which is connected to my BigBasket Account, I don’t need to authorize the payment again, since the mandate is set up. The order goes to AP2, AP2 then checks the instructions, and makes sure that they meet the conditions of the mandate. When the mandate is triggered, then it flows to the PA, which then executed it by sending relevant instructions to the network, the PSP, and so on. And then the payment executes without real-time user intervention.

➡️ User sets Intent Mandate which is stored in AP2 (this is the mandate set up + auth layer) ➡️ At the time of shopping, the LLM/Agent receives instruction, this could be chatGPT, Claude etc. ➡️ The LLM chat sends the instruction to AP2 ➡️ AP2 validates instruction against Intent Mandate ➡️ A cart mandate is created for that specific transaction which references Intent Mandate ➡️ Payment Mandate created which references Cart Mandate ➡️ The payment instruction is sent to the payment Aggregator / PA which is then sent to the Issuer Bank (which uses the creds / some sort of token I assume from the payment mandate to verify that this is a verified mandate) ➡️ Payment executed ➡️ Confirmation sent to AP2 to LLM and to the User

So this is similar to UPI Autopay (or rather UPI Reserve Pay, if funds are blocked) or Card on File standing instructions, except here the mandate is stored by the AP2 agent.

AP2 Implications for PSPs, Card Networks, and Banks

While the flow of money remains the same, there are certain things that are fundamentally changing. There is essentially a new authentication step here, where the stakeholders in the current flow - the PSP, the PA, the network, and the issuer and acquirer banks need to recognize mandates that are set up using the AP2 protocols as valid and compliant. So essentially:

That means:

• PSPs (like GPay, Razorpay, Stripe) must update their systems to accept AP2 payloads. Card networks (Visa, Mastercard) must support this in their frameworks, so a transaction initiated via an AP² agent still passes risk and auth checks (this I assume is happening, since both Visa and Mastercard are two players that are on this protocol as per Google). Banks / issuers must understand these as “authorized mandates”. The AP2 credential must be something that banks / issuers recognize as a valid authenticated instruction.

✅ Takeaways: AP2 introduces a new “trust layer” that existing payment systems must natively recognize as equivalent to direct user authentication, and thus the requirement for existing systems to recognize this. Unlike the OpenAI x Razorpay integration, which is a payment block set up and authenticated at the merchant, AP2 is a separate layer that stores the mandate, and in real time the payment request is mapped against the AP2 stored mandate. But all stakeholders have to be integrated with AP2, and recognize it as an authority

3️⃣ OpenAI & Stripe ACP Launch (Agentic Commerce Protocol)

The ACP here, like the MCP is a standard protocol that allows the agent, which in this case is OpenAI, send details directly to the merchant backend, which then speaks to Stripe, which is the payment processing layer. This also standardized authentication: how the agent identifies itself etc, so merchant’s need to create one standardized endpoint, and accept 1 standard way to authenticate the request, without having to do integrations for each LLM.

So, if you recall, in the earlier section, we talked about how there needs to be a way for the “order” placed in the LLM chat, to be translated into a “payment processing request” to Stripe in this case. The ACP is the layer that does this.

I’ve chalked out the steps that I’ve pieced together basis the OpenAI developer docs & the Stripe developer docs, and added the source material for anyone, if they want to inspect for themselves.

1. The user can access the merchant catalogue through the LLM chat: OpenAI (LLM chat) calls the Merchant MCP to fetch catalogue data. User browses options and selects an item (e.g., a blue pair of pants). Source: OpenAI ACP docs, Merchant MCP / Catalog

2. The user creates an order through the LLM chat: User says: “I want to buy this pair of pants.” LLM communicates with Merchant Backend via Merchant ACP to create an order and initiate payment request. Source: OpenAI ACP docs, Order Creation via ACP

3. Merchant backend creates order: Merchant backend sends order/payment request to Stripe (PSP / Payment Processor). Stripe has stored tokenized payment credentials of the user (assuming prior checkout or saved card). Source: Stripe docs, Delegated Payments

4. User initiates payment of the order: The user then sees the final order, along with the price and tax, and says pay now, in chatGPT

5. Payment authorization happens through a “delegated payment.”: Merchant ACP instructs Stripe to create a delegated payment, the payload contains a single-use token, which is scoped to specific order, merchant, and amount (e.g., INR 500), and limits potential exposure and misuse. Delegated payment token is returned to Merchant Backend. Now, it took me some time to understand this whole delegated payment concept, but unlike a mandate, this is created on the fly, and is a way of limiting exposure, by creating a token, to authorize payments for that specific order, on that merchant, for that time. Source: OpenAI ACP docs, Delegated Payments

6. Token ensures only the defined amount, merchant, and payment method can be charged. Merchant backend passes token to Stripe for processing. Source: Stripe docs, Delegated Payments Validation

7. ChatGPT then communicates with the merchant backend via the merchant ACP, which communicates with Stripe to create a “delegated payment.” This is the flow that is new here. The delegated payment creates the max payment limit of whatever the transaction amount of the order is, lets say INR 500. Now, Stripe also holds the tokenized payment details of the customer (assuming this customer has previously used this merchant, and saved their creds). The concept of the delegated payment here is to limit the exposure to a single payment, merchant & order and misuse. It’s like giving authorization for a very specific use case that limits exposure This delegated payment token is returned to the merchant backend, which validates the token, and then sends it to Stripe for processing.

8. Now, if there is no 2FA requirement, then the tokenized card is enough, and Stripe processes the payment instantly (which is your issuer + acquirer flow). If there is a 2FA requirement, then Stripe will trigger the OTP / PIN step, which can happen through some sort of embedded / deep link, or a secure webview.

   1. No 2FA: Stripe processes the payment instantly using sthe token.

   2. 2FA required: Stripe triggers OTP/PIN step via: embedded SDK, a secure webview, or a deep link from merchant backend. This is like a native payment today, when you enter your OTP on a native PA flow. Source: Stripe docs, 2FA / Strong Customer Authentication

9. Stripe confirms payment → Merchant Backend updates order status → LLM chat notifies the user of successful payment. Source: OpenAI ACP docs, Payment Confirmation Flow

✅ Takeaways: Here, the merchant account of the user has to be connected to OpenAI, and tokenized card details need to be stored at Stripe. Now, I did go through the OpenAI and Stripe documentation, and what the documentation says is that the delegated payment payload is generated for that specific transaction, so I assume that there are no pre-set rules required that Stripe / the merchant checks against, unlike UPI Reserve Pay, where a payment block is created, or like AP2, where a mandate has been created. So it is more autonomous in that sense, but the blocker here is that in SEA regions, where 2FA is a must, unless there is a mandate or a payment block set up in advance, it will never be truly autonomous.

❓ Agentic commerce for me in this way seems far more likely. Here’s my thought process. What LLM chats have done is given that “exponential experience, or as Kunal Shah postulates - the Delta 4 experience” for shopping, by providing a personalized, chat interface across different marketplaces (eventually). If you decouple the shopping experience, from the payments experience, the payments experience itself is fairly seamless now, with all the innovations around 1 click payments, PIN / native OTP entry and so on. I don’t know the additional value add of completely autonomous payments, especially if it comes with the additional headache in some cases of setting up a mandate. All I want is a way for me to make a payment or initiate the payment through the chat → and as a user, I’m more comfortable NOT sharing my PIN / OTP / secure details with the LLM. Using secure creds saved at the payment layer seems like a secure experience + coupled with on the fly payments.

❓Another point in my mind is that: everyone has their phone with them at all times. Even if a link is generated, which, basis the order placed, sends it to your payment app of choice, or a link to your whatsapp chat, through which you can pay through a secure interface, that also seems very likely.

4️⃣ Visa Trusted Agent Protocol (VISA TAP) for Agentic Commerce

Visa launched the its trusted agent protocol (TAP) in October 2025 to enable agentic commerce using stored / tokenized creds

1. The user can access the merchant catalogue through the LLM chat: OpenAI (LLM chat) calls the Merchant MCP to fetch catalogue data. User browses options and selects an item (e.g., a blue pair of pants).

2. The user creates an order through the LLM chat: User says: “I want to buy this pair of pants.” LLM communicates with Merchant Backend via Merchant ACP to create an order and initiate payment request, and sends the intent to the merchant app, which is registered as a Visa Trusted Agent.

3. Tokenized Card Retrieval (via PA). Merchant app requests tokenized Visa card from PA layer if stored there. LLM never accesses credentials directly. And of course, the PA also needs to support Visa TAP, and support in payment processing

4. Merchant Trusted Agent references stored credential: Merchant app looks up the user’s tokenized Visa card (saved at merchant checkout). Merchant app instructs Visa TAP to validate token + agent authority. TAP ensures only this merchant/agent can use this token.

5. Payment Authorization & Execution

   1. If 2FA required: Visa TAP triggers OTP / PIN / biometric via merchant app.

   2. If no 2FA required: Payment authorization happens instantly using the stored token.

6. Visa TAP communicates with the issuer bank to authorize and charge the card, PA handles settlement and routing

❓Again, this is just basis my understanding of the developer documentation, but this I assume will happen through some sort of delegated tokens, like Stripe ACP. Some open questions I have, which I couldn’t really figure out is how will the LLM know that the user has a stored Visa card? This protocol makes more sense to me at a PA layer, so that the customer can also choose which method to pay with, assuming all methods have been tokenized and stored at the checkout layer. Link to Visa developer docs here

Adoption of agentic payments really depends on how user behaviour evolves: I could argue both sides of this.

There are pros and cons of all approaches. My own perspective is: agent initiated payment is a must, and hence the need for protocols such as ACP & Visa Trusted Protocols, for secure payment initiation via the agent. But does it need to be autonomous? I’m leaning towards a no.

✅ The pros: if the hypothesis is that the shopping experience moves to LLMs, then it makes sense that you want the payment to happen there as well.

→ So payment initiation, sharing the context of shopping from the LLM to the merchant, and then creating an order via the LLM using merchant MCP & ACP. Yes, that makes a lot of sense. But I’m not sure if it’ll ever be truly autonomous, and I’m not sure if end users will even want it to be 100% autonomous. I do disagree with the concept of “invisible payments,” and my view is that friction is a feature here.

❓I’m still on the fence if the pre-set up payment block or the mandate style of agentic commerce will actually take off, in the case of AP2, or UPI Reserve Pay + OpenAI

1. This UPI reserve pay, or fund block will always have to be set up at a merchant level. Now, in the future, one may be able to set this up through the LLM Chat, through some sort of native experience, but even if you’re setting this up, this still requires one time auth, where you’re entering your PIN, or verifying using card details / OTP. And we may be still some ways away from the native use case

2. Mandates / SBMD can right now be set up at only a merchant level. So basically, these rules will have to be set up for each merchant. And then, it only makes sense if you transact from the same merchant multiple times in a fixed period: such as big basket, zomato etc

Also, while I’ve seen a lot of folks talk about agentic payments = invisible payments, but in financial services, friction isn’t always a flaw. Sometimes it is a feature

I remember speaking to a certain TSP that specialized in phone number authentication. And one of the tools that it provides are APIs for silent mobile verification. Which essentially allow user verification through APIs at the backend, instead of OTP verification. What I understand was, that the process is so seamless, that it had a negative experience on the users, where the user felt that the TSP was not doing rigorous enough checks. Finally the TSP actually had to add a few seconds of buffer at the time of log-in, so that the user was not taken aback at how seamless it is. And that is just for log-in.

And this is not a new idea. This is something that has been validated through multiple surveys. In fact, the Journal of Financial Services - The future of payments (2025) talks about “intelligent friction” where sometimes friction is not a flaw but a feature. And sometimes, taking that extra time to validate and authenticate reassures the customer, that all steps are being taken to ensure the transaction is not fraudulent.

Excerpt below from the Journal of Financial Services - The future of payments (2025)

Assuming AI / Agentic payments do take off, and they take off in this mandate based way, there are other additional pieces in play. There are multiple stakeholders in the current payment flow. And for this to take off at scale, changes need to happen at each step, which is what Google’s Agentic Payment Protocols are attempting to do.

While these AI payments have been piloted, if it was only a fintech problem, I’d be a lot more bullish. But this also requires system level changes to recognize the authority of new agents in the payment flow

I’ll give some examples:

👉 In the UPI Reserve Pay flow, this sort of payment works for cards - travel bookings etc. But this sits in the card management system. The debits & the credits from the savings account of the bank, sits in the core banking system. And currently, the bank CBS is not set up for this sort of payment at scale, along with other things such as reconciliation, fund flow etc. A simple example is the whole BNPL wave that hit India about 5-6 years ago. Bank systems, and the software providers they used were never set up to handle scenarios such as “grace period,” or “partial cancellation,” which were very obvious needs for consumer loans. Which resulted in a lot of manual handling.

👉 In the AP2 Mandates flow, the mandate is being set up and stored at the AP2 layer. So banks, and payment processors have to essentially recognize the validity and the authority of the AP2 mandate to actually process with processing the payment. So, again, changes required here

Until the system level changes are done, this may always stay just at a pilot stage, and never scale. I’ve talked about the resistance and the speed at which banks make changes more in this piece: #64: Innovation at the edges, stagnation at the core: why India needs neobanks

There are other issues here. Let us assume that somehow, this mandate flow works out in agentic commerce. To be able to truly make this mandate stuff work in an agentic way, you need to be able to set up it for a use case, or at some category. Setting it up at a per merchant basis, is going to be super time consuming. Example: I want to spend INR 10k on groceries every month. To enforce this, you basically need:

1. Merchants mapped to a category, i.e. MCC code

2. This mapping needs to exist somewhere centrally - example, at a network level, or at the agent / App level, so that in real time, the mandate can be checked to see if it fits the bill. And this mapping needs to be exposed as a database or through some APIs for real time checks.

3. The merchant to MCC mapping is constantly updated, and enforced, there are a lot of issues where merchant to MCC code is not mapped correctly, which can lead to all sorts of issues. This is still an issue at big PAs.

So regarding agentic payments, I have 4 questions:

1. How will customer behaviour evolve - this is a wait and watch: Is this experience truly head and shoulders above the current e-commerce experience. My view is: if we decouple → shopping is a yes, and payments is still a maybe. Using deep links, payment links, or even a redirection to enter the final payment, as long as the context of the order is shared should be enough, but that is my personal view. At the stage that this is, it is still subjective

2. Ease of use - mandates may bring additional set-up friction, is that off-set by the “autonomous” experience once mandate set up is done? Again, this remains to be seen. Setting up mandates at a merchant level seems cumbersome, and I’ve already explained some gaps in the “mandate set up by category” concept

3. Are “invisible payments” truly a need, or is friction a feature in payments? Again, while it is important to make payments as seamless as possible; no one wants to wait 10 minutes to pay, I still feel that that extra layer of authentication adds to the “trust” factor by a customer. The feeling being - hey there are additional steps so is is more secure.

4. Are current systems set up for agentic payments? I’m not talking about a flow such as UPI Reserve Pay here, which is happening via NPCI, an existing stakeholder. I’m talking about AP2, or even the OpenAI x Stripe ACP, and the Visa Trusted Protocols. There is a new authority at play here, be it AP2, with the mandate instruction, or Visa, with an authorized agent initiating payment. At the end of the day, it is the issuer that is approving, networks & PAs just play a role in facilitating. And, its not fintechs I’m talking about It is banks. Bank systems may be okay for a pilot, but are they okay to enable this at scale. I’m not certain.

From a banking systems perspective, for truly autonomous payments, alternative rails like stablecoins could offer a more efficient foundation for the next-generation AI-driven money movement layer.

We’ll dive deeper into this in the next edition. Stay tuned!