-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
paykit: create payments directly from the button #15
Conversation
/** | ||
* Optional nonce. If set, generates a deterministic payID. See docs. | ||
*/ | ||
nonce?: bigint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the nonce as in destNonce
onchain? Currently we always set nonce = payID onchain, and it's a nice invariant to enforce that the create2 parameters are publicly known by all parties. I'd recommend keeping that / not providing this option perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
invariant is still there. if you provide the nonce, that becomes the id. (Wrote "generates a determinstic payID" to avoid confusion because our payIds are formatted in base58.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
example use case in DonateForm:
- generate nonce
- on click, save (form info, payment nonce)
- then show checkout modal
this creates a guarantee that every payment is attributed.
--
maybe there's a cleaner way to support that.
we could usenewPayId
instead of nonce
, and we provide a utility function createRandomPayId
that returns the base58 form
then we don't have to expose concept of "nonce" in SDK
lmk if that feels cleaner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
update to use newPayId
to reduce confusion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
deleted newPayId
, just using onPaymentStarted for now
/** | ||
* Optional calldata to call an arbitrary function on `toAddress`. | ||
*/ | ||
toCallData?: Hex; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should all of these be folded into a recipient
?
recipient: {
address: `0x..`,
tokenAddress: `0x..`,
amount: 123n,
calldata: `0x..`,
}
Makes it easier in future if we have something like "Allowed recipients" to add a recipient: {id: "1234.."}
option
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allowed recipients might be just the contracts (address + chain ID), right?
the calldata and amount still has to vary payment to payment. eg ethOS would whitelist their minting contract on Base.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one other place where IDs would be useful is bank accounts.
some ideas
Send $20.00 to a bank account
recipient={{
id: "06b0e3e3-91a6-4b09-bffe-46eab58ffa18",
currency: "USD",
quantity: "20.00"
}}
vs
toAccount="06b0e3e3-91a6-4b09-bffe-46eab58ffa18"
toCurrency="USD"
toQuantity="20.00"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated. using toUnits
to match Viem convention
/** | ||
* Preferred chain IDs. Assets on these chains will appear first. | ||
*/ | ||
preferredChains?: number[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no preferredToken
? fine if no one needs it but I actually thought that was the one people like ethOS wanted (and this one hasn't been used by anyone yet)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added.
const { paymentState } = context; | ||
useEffect( | ||
() => { | ||
if ("payId" in props) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't think this is ever true? how does this work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we still support <DaimoPayButton payId={...} />
used eg. for our own hosted page
address?: Hash; | ||
truncatedAddress?: string; | ||
ensName?: string; | ||
payId?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need payId
and intent
if we put text in the button from the payment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with the new style, the payment isn't saved till hydration. we do generate what the payId will be, but might be confusing to pass thru payId
that doesn't exist when looked up in API
can pass thru intent, but this is the client's own page, right? say they make a custom Donate button + make the payment with intent=Donate so modal shows nicely
@@ -56,17 +56,12 @@ function getDepositAddressOption(depositAddressOptions: { | |||
}) { | |||
const { setRoute } = usePayContext(); | |||
|
|||
console.log( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
log
?
trpc.processSolanaSourcePayment.mutate({ | ||
orderId: orderId.toString(), | ||
startIntentTxHash: txHash, | ||
amount: chosenFinalTokenAmount, | ||
amount: "0", // TODO: replace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the best way to get the amount of input token sent from the txHash
(not sure how receipts work on Solana... do they have something like the Transfer event log we can fetch?)
- we are using an exact-output swap, so we don't know how much input token will be consumed upfront, only once it's onchain
- the previous code was substituting a totally different amount (different token, different decimals) as far as i can tell
packages/connectkit/src/index.ts
Outdated
// These first two just return configured wagmi chains = not necessarily | ||
// supported by Daimo Pay. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean? If dev uses getDefaultConfig
as we intend them to those are equivalent?
*/ | ||
preferredChains?: number[]; | ||
} | ||
| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should put functional onPaymentStarted
, onPaymentCompleted
, onPaymentBounced
etc here? Currently if the modal generates a payment, the dev has no way to obtain the ID afaict? (they may want to track it in their backend / webhooks etc later)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
100%, coming soon.
d6de290
to
b6963e6
Compare
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
|
Token sort working againLooks like it was broken for a while in prod. Bugfixed. |
Basic
Contract
Checkout
Pregenerated payID: