Apple implements interledger in safari on iOS

[XRPisVELOCITY]

13 minutes ago, OzAlphaWolf said:

Well yeh, of course Ripple Net consumes drops for fees, but this is about ILP.

Correct.  Can be used on any network.

[Ralphadayus]

1 minute ago, Ralphadayus said:

Looks like I was wrong. Here's some good info: https://ripple.com/build/transaction-cost/

Well, half right, haha. https://ripple.com/build/fee-voting/

[TexasHodlem]

@Quintree @Hodlezerper

Readers, sorry for the code. Skip those bits and read the text in between and it should still make sense.

All we know for sure is that Safari has implemented the Payment Request API and that Apple Pay is able to receive these requests from the browser. (source: https://webkit.org/blog/8182/introducing-the-payment-request-api-for-apple-pay/)

When a payment request is created, one of the parameters is a list of supported methods. From https://developers.google.com/web/fundamentals/payments/deep-dive-into-payment-request :

const supportedPaymentMethods = [
  {
    supportedMethods: 'basic-card',
  }
];
const paymentDetails = {
  total: {
    label: 'Total',
    amount:{
      currency: 'USD',
      value: 0
    }
  }
};
// Options isn't required.
const options = {};

new PaymentRequest(
  supportedPaymentMethods,
  paymentDetails,
  options
);

Note supportedMethods: "basic-card" at the top. This was (and I think still is) the only standardized payment method identifier. (source: https://www.w3.org/TR/payment-method-id/#registry) However, the specification *also* allows for URL based payment methods so that application specific payment methods can be used without every browser needing to know about them in advance. For example, GooglePay (and I assume ApplePay similarly) is implemented through this URL method as follows:

const googlePayPaymentMethod = {
  supportedMethods: 'https://google.com/pay',
  data: {
    'environment': 'TEST',
    'apiVersion': 1,
    'allowedPaymentMethods': ['CARD', 'TOKENIZED_CARD'],
    'paymentMethodTokenizationParameters': {
      'tokenizationType': 'PAYMENT_GATEWAY',
      // Check with your payment gateway on the parameters to pass.
      'parameters': {}
    },
    'cardRequirements': {
      'allowedCardNetworks': ['AMEX', 'DISCOVER', 'MASTERCARD', 'VISA'],
      'billingAddressRequired': true,
      'billingAddressFormat': 'MIN'
    },
    'phoneNumberRequired': true,
    'emailRequired': true,
    'shippingAddressRequired': true
  },
};

 

The proposal at https://w3c.github.io/webpayments/proposals/interledger/ defines a payment method with the standardized identifier "interledger". Without testing Safari, I can't say for certain whether using supportedMethods: "interledger" (instead of the known standard supportedMethods: "basic-card") will work. What is clear is that the specification can be used via URL, even if it's not included in the registry as "interledger" yet. Remember that the browser doesn't actually make payments through the API, it simply requests data that it needs in order to process the payment on the back end. Different payment methods require different data (an XRP payment shouldn't request a credit card number), so those parameters need to be defined somewhere. In this case, if ApplePay doesn't understand how to provide data for a field requested for the ILP payment request, then a different wallet must be used or user input may be required. I don't have the answer for how to fix that at this time (and this post is already getting windy).

In conclusion, even if it's just "basic-card" (for debit/credit) that's implemented with the Payment Request API right now, it's a VERY short leap to adding other payment methods. To me, this is exciting news.

TL;DR; HODL.

Edited April 7, 2018 by TexasHodlem

[manateehunter]

14 minutes ago, TexasHodlem said:

@Quintree @Hodlezerper

Readers, sorry for the code. Skip those bits and read the text in between and it should still make sense.

All we know for sure is that Safari has implemented the Payment Request API and that Apple Pay is able to receive these requests from the browser. (source: https://webkit.org/blog/8182/introducing-the-payment-request-api-for-apple-pay/)

When a payment request is created, one of the parameters is a list of supported methods. From https://developers.google.com/web/fundamentals/payments/deep-dive-into-payment-request :

const supportedPaymentMethods = [
  {
    supportedMethods: 'basic-card',
  }
];
const paymentDetails = {
  total: {
    label: 'Total',
    amount:{
      currency: 'USD',
      value: 0
    }
  }
};
// Options isn't required.
const options = {};

new PaymentRequest(
  supportedPaymentMethods,
  paymentDetails,
  options
);

Note supportedMethods: "basic-card" at the top. This was (and I think still is) the only standardized payment method identifier. (source: https://www.w3.org/TR/payment-method-id/#registry) However, the specification *also* allows for URL based payment methods so that application specific payment methods can be used without every browser needing to know about them in advance. For example, GooglePay (and I assume ApplePay similarly) is implemented through this URL method as follows:

const googlePayPaymentMethod = {
  supportedMethods: 'https://google.com/pay',
  data: {
    'environment': 'TEST',
    'apiVersion': 1,
    'allowedPaymentMethods': ['CARD', 'TOKENIZED_CARD'],
    'paymentMethodTokenizationParameters': {
      'tokenizationType': 'PAYMENT_GATEWAY',
      // Check with your payment gateway on the parameters to pass.
      'parameters': {}
    },
    'cardRequirements': {
      'allowedCardNetworks': ['AMEX', 'DISCOVER', 'MASTERCARD', 'VISA'],
      'billingAddressRequired': true,
      'billingAddressFormat': 'MIN'
    },
    'phoneNumberRequired': true,
    'emailRequired': true,
    'shippingAddressRequired': true
  },
};

 

The proposal at https://w3c.github.io/webpayments/proposals/interledger/ defines a payment method with the standardized identifier "interledger". Without testing Safari, I can't say for certain whether using supportedMethods: "interledger" (instead of the known standard supportedMethods: "basic-card") will work. What is clear is that the specification can be used via URL, even if it's not included in the registry as "interledger" yet. Remember that the browser doesn't actually make payments through the API, it simply requests data that it needs in order to process the payment on the back end. Different payment methods require different data (an XRP payment shouldn't request a credit card number), so those parameters need to be defined somewhere. In this case, if ApplePay doesn't understand how to provide data for a field requested for the ILP payment request, then a different wallet must be used or user input may be required. I don't have the answer for how to fix that at this time (and this post is already getting windy).

In conclusion, even if it's just "basic-card" (for debit/credit) that's implemented with the Payment Request API right now, it's a VERY short leap to adding other payment methods. To me, this is exciting news.

TL;DR; HODL.

I'm gonna have to re-take my edx blockchain course cause of you.

Edited April 7, 2018 by manateehunter

[CryptoJym]

So Moon? 

[Mr-MagicRipplehat]

1 hour ago, OzAlphaWolf said:

No, because for example, a EUR transaction could cross the ILP, but where is the requirement to have XRP held somewhere to cover fees. Connectors can withhold a small portion of a transfer as their payment but that doesn't necessarily have to be in XRP. 

And xRapid is the system that uses the pathfinder for getting the cheapest rate on Fiat/XRP, XRP/Fiat legs. But since the ILP doesn't need that I don't see how XRP needs to be involved at all, even as drops for transaction fees.

Yeah, but if ripple net choses the fastest option. Let's say, you buy from in Brazil, so somewhere it will need to be converted to USD. That means Xrapid will be the fastest option. If the bank of user A and the receiving bank of Apple is connected with Xrapid through ripple net. That means XRP will be used.

If, Xvia is for businesses to pay their employees, than Xpool surely is a software to receive payments. Looking at the future, i see XRP becoming global, so it's a solution to a problem.
But, that's probably the end goal. 
Even though, this is huge news. The more important notice here is that nostro/vostro accounts' days are gone. Finito...

Edited April 7, 2018 by Mr-MagicRipplehat

[Guest]

Thank you for all the excellent contributions and notes everyone! Especially for those of us who are less technical this has certainly been a helpful thread.

That said....step by step. Lets not jump too far ahead of ourselves.

 

[amulecregg]

Wait! Does the ILP draft actually mean the Payment Request API is using it?

[TexasHodlem]

I couldn't help myself, so I modified some sample code from Google to prove the status of the interledger payment method. If there's someone with Safari on here, please let us know if it says "interledger supported" in the lower-right section of the page with a white background. In Chrome, it indeed shows that interledger is NOT supported. A browser without any support for the API will indicate so. Clicking the button launches the payment interface with the "basic-card" method.

https://jsfiddle.net/wzawsLeb/

I also looked into third party wallet support, and it appears that at this time, there isn't any, but they do say "coming soon". A connector for plug-ins or third party wallet applications is left to the specific browser/operating system platform. That means we can't (yet) write an XRP Wallet for Chrome.

Quote

A payment method can be as straightforward as a credit card that is already stored by the browser, or as esoteric as a third-party system (for example, Android Pay or PayPal) written specifically to deliver payments to the site (this functionality is coming soon).

https://developers.google.com/web/ilt/pwa/introduction-to-the-payment-request-api

 

[TexasHodlem]

9 minutes ago, amulecregg said:

Wait! Does the ILP draft actually mean the Payment Request API is using it?

No. My prior posts shed some light on this. The short version: it's up to the browser to implement support for each payment method, or to implement a way for a third-party app that does support it to interface with the browser.

[NickManning]

15 minutes ago, TexasHodlem said:

I couldn't help myself, so I modified some sample code from Google to prove the status of the interledger payment method. If there's someone with Safari on here, please let us know if it says "interledger supported" in the lower-right section of the page with a white background. In Chrome, it indeed shows that interledger is NOT supported. A browser without any support for the API will indicate so. Clicking the button launches the payment interface with the "basic-card" method.

https://jsfiddle.net/wzawsLeb/

I also looked into third party wallet support, and it appears that at this time, there isn't any, but they do say "coming soon". A connector for plug-ins or third party wallet applications is left to the specific browser/operating system platform. That means we can't (yet) write an XRP Wallet for Chrome.

 

Just checked Brave browser and it's not yet supported then again, it's based on chromium. I'm sure Brendan will be ahead of the curve on this one, though. Thank you for your work! Also, I hate you because it's yet another thing I'll be checking all day like a madman!!!

Edited April 7, 2018 by NickManning

[Danny]

Thanks @Tehol_Beddict you always have interesting posts.

[Spartaksus]

4 hours ago, Hodlezerper said:

Not really. It uses credit cards.

It use payment cards because there isn´t  any other world-wide accepted payment alternative. Apple is tired of dealing with banks (mostly due to slow  progress in adoption of MC/VISA tokenization), banks on the other hand don´t like Apple pricing policy for Apple Pay. So I completely understand Apple is looking for some cheaper, faster, easy to adopt/manage alternative. The same case is Google.

[RecentChange]

As an example of what ILP can do, watch this demo by stefan thomas: 

It doesn't use Safari browser but gives you an idea of what is possible.

 

[Guest]

5 hours ago, Hodlezerper said:

Does anyone who's technically savvy mind telling me why this isn't a big deal? Cause otherwise I'm going to assume this is huge. 

(really what I'm getting at is, will they be using interledger to access other payment schemes, like bank to bank, domestic transfers, etc? Or is interledger strictly digital asset based)

This IS huge. But that will only be clear after the first sites pop up that actually *use* it. Then, the IoV starts, for everyone to see.