@@ -594,10 +594,26 @@ impl RecipientOnionFields {
594
594
/// Note that if this field is non-empty, it will contain strictly increasing TLVs, each
595
595
/// represented by a `(u64, Vec<u8>)` for its type number and serialized value respectively.
596
596
/// This is validated when setting this field using [`Self::with_custom_tlvs`].
597
+ #[ cfg( not( c_bindings) ) ]
597
598
pub fn custom_tlvs ( & self ) -> & Vec < ( u64 , Vec < u8 > ) > {
598
599
& self . custom_tlvs
599
600
}
600
601
602
+ /// Gets the custom TLVs that will be sent or have been received.
603
+ ///
604
+ /// Custom TLVs allow sending extra application-specific data with a payment. They provide
605
+ /// additional flexibility on top of payment metadata, as while other implementations may
606
+ /// require `payment_metadata` to reflect metadata provided in an invoice, custom TLVs
607
+ /// do not have this restriction.
608
+ ///
609
+ /// Note that if this field is non-empty, it will contain strictly increasing TLVs, each
610
+ /// represented by a `(u64, Vec<u8>)` for its type number and serialized value respectively.
611
+ /// This is validated when setting this field using [`Self::with_custom_tlvs`].
612
+ #[ cfg( c_bindings) ]
613
+ pub fn custom_tlvs ( & self ) -> Vec < ( u64 , Vec < u8 > ) > {
614
+ self . custom_tlvs . clone ( )
615
+ }
616
+
601
617
/// When we have received some HTLC(s) towards an MPP payment, as we receive further HTLC(s) we
602
618
/// have to make sure that some fields match exactly across the parts. For those that aren't
603
619
/// required to match, if they don't match we should remove them so as to not expose data
0 commit comments